AWS Bedrock ಕೀಲಿಗಳು ಈಗ ಆಂತರಿಕ LLM ಗೇಟ್ವೇಯಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿವೆ, ಇದು ಫಿನ್ಟೆಕ್ ಸಂಸ್ಥೆಯ ಪ್ರತಿಯೊಂದು ತಂಡವು ಮಾಡೆಲ್ಗಳನ್ನು ಬಳಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಆದರೂ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯು (request) ಪ್ರತಿ ತಂಡಕ್ಕೆ ನಿಗದಿಪಡಿಸಿದ ಟೋಕನ್ ಬಜೆಟ್ಗೆ ಬದ್ಧವಾಗಿರುತ್ತದೆ. ಈ ಬದಲಾವಣೆಯು ರೆಪೊಸಿಟರಿಗಳು ಮತ್ತು ನೋಟ್ಬುಕ್ಗಳಲ್ಲಿ IAM ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ಹರಡುವ ಅಭ್ಯಾಸವನ್ನು ತಡೆಯುತ್ತದೆ, ಈ ಅಭ್ಯಾಸವು ಈಗಾಗಲೇ ಒಂದು ಮಧ್ಯಾಹ್ನದಲ್ಲೇ ಕಂಪನಿಯ AI ವೆಚ್ಚವನ್ನು ಖಾಲಿ ಮಾಡುವ ಭೀತಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತಿತ್ತು.
AWS ಕೀಲಿಗಳನ್ನು ಹಂಚುವುದು ಹೇಗೆ ಬೇಗನೆ ಗೊಂದಲಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ
ಸಂಸ್ಥೆಯ ತಾಂತ್ರಿಕವಲ್ಲದ ಗುಂಪುಗಳು ಕಂಪನಿಯ ಭಾಷಾ ಮಾದರಿಗಳಿಗೆ (language models) ನೇರ ಪ್ರವೇಶವನ್ನು ಕೇಳಿದವು. ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಅತ್ಯಂತ ಸರಳವಾದ ಉತ್ತರವೆಂದರೆ AWS ನಲ್ಲಿ ಮಾಡೆಲ್ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಮತ್ತು ಪ್ರತಿ ಗುಂಪಿಗೆ IAM ಅನುಮತಿಯನ್ನು ನೀಡುವುದು. ಹತ್ತು ನಿಮಿಷದ ಕೆಲಸ, ಕೆಲವು ಪಾಲಿಸಿ ಎಡಿಟ್ಗಳು, ಮತ್ತು ಕೆಲಸ ಮುಗಿದುಹೋಗುತ್ತಿತ್ತು—ಕನಿಷ್ಠ ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಮಾತ್ರ.
ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, IAM ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ಹಂಚುವುದು ಮೂರು ಗುಪ್ತ ವೆಚ್ಚಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ:
- ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಹರಡುವಿಕೆ (Credential sprawl) – ಕೀಲಿಗಳು
.envಫೈಲ್ಗಳು, CI ಪೈಪ್ಲೈನ್ಗಳು, Jupyter ನೋಟ್ಬುಕ್ಗಳು ಮತ್ತು ಅಡ್-ಹಾಕ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳಲ್ಲಿ ಸೇರಿಕೊಳ್ಳುತ್ತವೆ. ಕೀಲಿಗಳನ್ನು ಬದಲಾಯಿಸುವ (rotation) ಅಗತ್ಯವಿದ್ದಾಗ, ಪ್ರತಿ ಪ್ರತಿರೂಪವೂ ವೈಫಲ್ಯದ ಅಂಶವಾಗುತ್ತದೆ. - ಶೂನ್ಯ ದೃಶ್ಯ ಗೋಚರತೆ (Zero visibility) – ಒಂದೇ ಹಂಚಿಕೆಯ ಕೀಲಿಯು ಯಾವ ತಂಡ ಅಥವಾ ಯಾವ ಕೋಡ್ ಬಳಕೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತಿದೆ ಎಂಬ ಸುಳಿವು ನೀಡುವುದಿಲ್ಲ. ನಿಯಂತ್ರಣ ಮೀರಿ ಹೋದ ಲೂಪ್ (runaway loop) ಪ್ರಾರಂಭವಾದಾಗ, ಯಾರೂ ಗಮನಿಸುವ ಮೊದಲೇ ಇಡೀ ಬಜೆಟ್ ಖಾಲಿಯಾಗಬಹುದು.
- ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆ (Operational overhead) – ಯಾರಿಗೆ ಯಾವ ಅನುಮತಿ ಇದೆ ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು, ಪ್ರವೇಶವನ್ನು ರದ್ದುಗೊಳಿಸುವುದು ಮತ್ತು ಬಳಕೆಯನ್ನು ಆಡಿಟ್ ಮಾಡುವುದು ಶೀಘ್ರದಲ್ಲೇ ಕೈಯಿಂದ ಮಾಡುವ, ತಪ್ಪುಗಳಿಗೆ ಒಳಗಾಗುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿ ಬದಲಾಗುತ್ತದೆ.
ಫಿನ್ಟೆಕ್ ತಂಡವು ಈ "ತ್ವರಿತ ಪರಿಹಾರವು" ಶೀಘ್ರದಲ್ಲೇ ಭದ್ರತೆ ಮತ್ತು ವೆಚ್ಚದ ದುಸ್ವಪ್ನವಾಗಲಿದೆ ಎಂದು ಅರಿತುಕೊಂಡಿತು.
ಬದಲಾಗಿ ರಿವರ್ಸ್-ಪ್ರೊಕ್ಸಿ ಗೇಟ್ವೇಯನ್ನು ನಿರ್ಮಿಸುವುದು
ಪರಿಹಾರವೆಂದರೆ ಪ್ರತಿಯೊಂದು ಆಂತರಿಕ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು AWS Bedrock ನಡುವೆ ಒಂದು ತೆಳುವಾದ ರಿವರ್ಸ್ ಪ್ರೊಕ್ಸಿಯನ್ನು ಸೇರಿಸುವುದು. ಈ ಪ್ರೊಕ್ಸಿಯು ನೈಜ AWS ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ಒಂದು ವಾಲ್ಟ್ನಿಂದ ಸುರಕ್ಷಿತಗೊಳಿಸಲಾದ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಕರೆಯುವವರಿಗೆ ಅಲ್ಪಾವಧಿಯ, ಮನುಷ್ಯರು ಓದಬಲ್ಲ ಟೋಕನ್ಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, lllkey_9f3c) ನೀಡುತ್ತದೆ.
ಪ್ರಮುಖ ವಿನ್ಯಾಸದ ಅಂಶಗಳು:
- ಯಾವುದೇ AWS ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳು ಗೇಟ್ವೇಯನ್ನು ಬಿಟ್ಟು ಹೊರಗೆ ಹೋಗುವುದಿಲ್ಲ – ಡೆವಲಪರ್ಗಳು ಮತ್ತು ಸೇವೆಗಳು ಎಂದಿಗೂ ನೈಜ IAM ಕೀಲಿಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ.
- ಪ್ರತಿ-ಟೋಕನ್ ನೀತಿ ಜಾರಿ (Per-token policy enforcement) – ಪ್ರತಿ ಟೋಕನ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟ ಮಾಡೆಲ್ ಕುಟುಂಬಕ್ಕೆ ಅಥವಾ ಗರಿಷ್ಠ ಟೋಕನ್ ಸಂಖ್ಯೆಗೆ ಸೀಮಿತಗೊಳಿಸಬಹುದು.
- ಸಂಪೂರ್ಣ ಆಡಿಟ್ ಟ್ರೈಲ್ (Full audit trail) – ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯನ್ನು ಹೆಸರಿನೊಂದಿಗೆ ಲಾಗ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಗೇಟ್ವೇಯು ವಿನಂತಿಯನ್ನು (request) ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ
- ಟೋಕನ್ ಸ್ವೀಕರಿಸುವುದು – ಕ್ಲೈಂಟ್ ತನ್ನ
llmkey_…ಟೋಕನ್ ಅನ್ನು HTTP ಹೆಡರ್ನಲ್ಲಿ ಒಳಗೊಂಡಿರುತ್ತದೆ. - ಟೋಕನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು – ಗೇಟ್ವೇಯು ಟೋಕನ್ನ ಸ್ಥಿತಿಯನ್ನು (ಸಕ್ರಿಯವಾಗಿದೆ ಅಥವಾ ಅವಧಿ ಮುಗಿದಿದೆಯೇ) ಮತ್ತು ವಿನಂತಿಯು ನಿಗದಿಪಡಿಸಿದ ಬಜೆಟ್ನೊಳಗೆ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ.
- ಮಾಡೆಲ್ ವೈಟ್ಲಿಸ್ಟ್ – ವಿನಂತಿಸಿದ ಮಾಡೆಲ್ ಆ ಟೋಕನ್ಗೆ ಅನುಮತಿಸಲಾಗಿದೆಯೇ ಎಂದು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
- Bedrock ಗೆ ಕಳುಹಿಸುವುದು – ಸಂಗ್ರಹಿಸಲಾದ IAM ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ಬಳಸಿ ವಿನಂತಿಯನ್ನು AWS ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
- ಲಾಗ್ ಮತ್ತು ಬಿಲ್ಲಿಂಗ್ – ವರದಿಗಾಗಿ ಟೋಕನ್ ಬಳಕೆ, ಮಾಡೆಲ್ ಹೆಸರು ಮತ್ತು ವೆಚ್ಚದ ಅಂದಾಜನ್ನು ಕೇಂದ್ರ ಡೇಟಾಬೇಸ್ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ.
ಫಿನ್ಟೆಕ್ ಸಂಸ್ಥೆಯು ತನ್ನ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ತನ್ನದೇ ಆದ ನೆಟ್ವರ್ಕ್ ಒಳಗೆ ಇರಿಸಿಕೊಳ್ಳಬೇಕಿರುವುದರಿಂದ, ಮೂರನೇ ಪಾರ್ಟಿ SaaS ಸೇವೆಯನ್ನು ಬಳಸುವ ಆಯ್ಕೆಯನ್ನು ಕೈಬಿಡಲಾಯಿತು.
ಕಂಪನಿಯು ಏನನ್ನು ಪಡೆದುಕೊಂಡಿತು
- ಮಾಡೆಲ್ ನಿಯಂತ್ರಣ – ಕಡಿಮೆ ವೆಚ್ಚದ ಮಾಡೆಲ್ ಅಗತ್ಯವಿರುವ ತಂಡಗಳನ್ನು ಅದಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಬಹುದು, ಇದರಿಂದ ದುಬಾರಿ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಾಮರ್ಥ್ಯದ ಮಾಡೆಲ್ಗಳ ಅಕಸ್ಮಾತ್ ಬಳಕೆಯನ್ನು ತಡೆಯಬಹುದು.
- ಬಜೆಟ್ ರಕ್ಷಣೆ – ಟೋಕನ್ಗಳಿಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಟೋಕನ್ ಮಿತಿಯಿದೆ. ಮಿತಿ ತಲುಪಿದಾಗ, ಗೇಟ್ವೇಯು ಹೆಚ್ಚಿನ ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಬಳಸುವ ಬದಲು ದೋಷವನ್ನು (error) ನೀಡುತ್ತದೆ.
- ಹಣಕಾಸು ವಿಭಾಗಕ್ಕಾಗಿ ವಿವರಣೆ (Attribution for finance) – ಬಳಕೆಯ ಲಾಗ್ಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಡ್ಯಾಶ್ಬೋರ್ಡ್, ಯಾವ ತಂಡ ಅಥವಾ ಸೇವೆ AI ಮೇಲೆ ಎಷ್ಟು ಖರ್ಚು ಮಾಡಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತೋರಿಸುತ್ತದೆ, ಇದು ಅಸ್ಪಷ್ಟ ಸ್ಪ್ರೆಡ್ಶೀಟ್ ಅನ್ನು ಪಾರದರ್ಶಕ ವರದಿಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯವಿಧಾನವೂ ಬದಲಾಯಿತು. ಯಾವುದೇ ಹೊಸ IAM ಪಾಲಿಸಿಗಳ ಅಗತ್ಯವಿಲ್ಲ, ಯಾವುದೇ ಸೀಕ್ರೆಟ್ ರೊಟೇಶನ್ ಇಲ್ಲ ಮತ್ತು ಕೀಲಿಗಳು ವರ್ಷನ್ ಕಂಟ್ರೋಲ್ಗೆ ಸೋರಿಕೆಯಾಗುವ ಅಪಾಯವಿಲ್ಲ.
ವಿರೋಧಾತ್ಮಕ ವಾದ: ಮ್ಯಾನೇಜ್ಡ್ ಸೇವೆಯನ್ನು ಏಕೆ ಬಳಸಬಾರದು
ಕಸ್ಟಮ್ ಗೇಟ್ವೇಯನ್ನು ನಿರ್ಮಿಸುವುದು ಇಂಜಿನಿಯರಿಂಗ್ ಶ್ರಮ ಮತ್ತು ನಿರ್ವಹಣೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಎಂಬುದು ಸಾಮಾನ್ಯ ಆಕ್ಷೇಪಣೆಯಾಗಿದೆ. ಫಿನ್ಟೆಕ್ ಸಂಸ್ಥೆಯ ವಿಷಯದಲ್ಲಿ, ಎಲ್ಲಾ AI ಟ್ರಾಫಿಕ್ ಮತ್ತು ಬಳಕೆಯ ಡೇಟಾವನ್ನು ಕಾರ್ಪೊರೇಟ್ ಫೈರ್ವಾಲ್ ಹಿಂದೆ ಇರಿಸಿಕೊಳ್ಳುವ ಅಗತ್ಯವು ಮೂರನೇ ಪಾರ್ಟಿ ಪರಿಹಾರದ ಅನುಕೂಲಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿತ್ತು. ಆಂತರಿಕ ಪ್ರೊಕ್ಸಿಗೆ ವೀಕೆಂಡ್ನಷ್ಟು ಅಭಿವೃದ್ಧಿಯ ಸಮಯ ಬೇಕಾಯಿತು, ಆದರೆ ಇದು ಅಜಾಗರೂಕ ಕೀ-ವಿತರಣಾ ವಿಧಾನದಿಂದ ಉಂಟಾಗಬಹುದಾಗಿದ್ದ ತಿಂಗಳುಗಳ ಕಾಲದ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಕ್ಲೀನಪ್ ಮತ್ತು ಬಜೆಟ್ ಮಿತಿ ಮೀರುವಿಕೆಯನ್ನು ತಪ್ಪಿಸಿತು.
ಸಾರಾಂಶ (Takeaway)
AWS Bedrock ಕೀಲಿಗಳನ್ನು ಹಂಚುವುದು ಒಂದು ಶಾರ್ಟ್ಕಟ್ ಆಗಿದ್ದು, ಅದು ಬೇಗನೆ ಭದ್ರತೆ ಮತ್ತು ಬಜೆಟ್ ನಿರ್ವಹಣೆಯ ದುಸ್ವಪ್ನವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ವೀಕೆಂಡ್ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಒಂದು ಸಾಧಾರಣ ರಿವರ್ಸ್-ಪ್ರೊಕ್ಸಿ ಗೇಟ್ವೇಯು ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ, ಪ್ರತಿ ತಂಡದ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೆ ತರುತ್ತದೆ ಮತ್ತು ಹಣಕಾಸು ವಿಭಾಗಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಆಡಿಟ್ ಟ್ರೈಲ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ನಿಯಂತ್ರಣವನ್ನು ಬಿಟ್ಟುಕೊಡದೆ ಅನೇಕ ಗುಂಪುಗಳು LLM ಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡಲು ಬಯಸುವ ಯಾವುದೇ ಸಂಸ್ಥೆಗೆ, ಈ ಗೇಟ್ವೇ ವಿಧಾನವು ಸಂಭವಿಸಬಹುದಾದ ಘಟನೆಗಳನ್ನು ತಪ್ಪಿಸುವ ಮೂಲಕ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ವೆಚ್ಚದ ದೃಶ್ಯ ಗೋಚರತೆಯನ್ನು ನೀಡುವ ಮೂಲಕ ತನ್ನ ಲಾಭವನ್ನು ತಾನೇ ತಂದುಕೊಡುತ್ತದೆ.