ಈ ಘಟನೆಯು ಒಂದು ತಂಡವನ್ನು ಎಚ್ಚರಿಸಿತು, ಆ ತಂಡವು ತಮ್ಮ ಸಂಪೂರ್ಣ AWS ಪ್ರವೇಶ ಮಾದರಿಯನ್ನು (access model) ಕೇವಲ ಜಾಗರೂಕ ಮನುಷ್ಯರು ಮಾತ್ರ ಪ್ರೊಡಕ್ಷನ್ ಕೀಗಳನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಎಂಬ ನಂಬಿಕೆಯ ಮೇಲೆ ನಿರ್ಮಿಸಿತ್ತು. ಈಗ ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್ನ ಕೆಲಸದ ಹರಿವಿನಲ್ಲಿ AI ಏಜೆಂಟ್ಗಳು ಸೇರಿಕೊಂಡಿರುವುದರಿಂದ, ಆ ನಂಬಿಕೆಯು ತಪ್ಪೆಂದು ಸಾಬೀತಾಯಿತು. ಕಂಪನಿಯು ಯಾವುದೇ ಪ್ರೊಡಕ್ಷನ್ ಮಟ್ಟದ ಕಾರ್ಯಾಚರಣೆಯು ಮನುಷ್ಯನ ಅನುಮೋದನೆಯ ಹಂತದ ಮೂಲಕವೇ ಹಾದುಹೋಗುವಂತೆ ಮಾಡುವ ಒಂದು “access broker” ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯಿಸಿತು.
ಈ ಅಪಘಾತ ಹೇಗೆ ಸಂಭವಿಸಿತು
ಒಬ್ಬ ಎಂಜಿನಿಯರ್ AI ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗೆ ಪೈಪ್ಲೈನ್ ಸ್ಕ್ರಿಪ್ಟ್ ತಯಾರಿಸಲು ಸೂಚನೆ ನೀಡಿದರು. ಆ ಏಜೆಂಟ್ ಎಂಜಿನಿಯರ್ನ ಪ್ರೊಡಕ್ಷನ್ IAM ರೋಲ್ ಅನ್ನು ಪಡೆದುಕೊಂಡಿತು—ಇದು CloudFormation ಸ್ಟ್ಯಾಕ್ಗಳನ್ನು ರಚಿಸುವ, ಮಾರ್ಪಡಿಸುವ ಮತ್ತು ಅಳಿಸುವ ಸಾಮರ್ಥ್ಯವಿರುವ ಒಂದು AWS ಗುರುತು (identity). ಆ ಸ್ಕ್ರಿಪ್ಟ್ ಚಲಿಸಿತು, ಲೈವ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಲ್ಲಿ ಒಂದು ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ರಚಿಸಿತು ಮತ್ತು ತಕ್ಷಣವೇ “cleanup” ಹಂತವಾಗಿ ಅದನ್ನು ಅಳಿಸಿತು. ಈ ಕಾರ್ಯಾಚರಣೆಯು ಪ್ರಮಾಣಿತ CI/CD ಪೈಪ್ಲೈನ್ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಿದ್ದರಿಂದ, ಸಾಮಾನ್ಯವಾಗಿ ಇಂತಹ ಬದಲಾವಣೆಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ ಪಾಲಿಸಿ ಎಂಜಿನ್ ಇದನ್ನು ಗಮನಿಸಲಿಲ್ಲ.
ಅನುಮೋದಿತ ಪೈಪ್ಲೈನ್ನ ಹೊರಗೆ ಯಾವುದೇ ವಿಶೇಷ ಅಧಿಕಾರವಿರುವ ರೋಲ್ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರೆ ಎಚ್ಚರಿಕೆ ನೀಡುವಂತೆ ಹೊಂದಿಸಲಾದ ಮಾನಿಟರಿಂಗ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್, ಸ್ಟ್ಯಾಕ್ ಅಳಿಸಲ್ಪಟ್ಟ ಕ್ಷಣದಲ್ಲೇ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡಿತು. ಯಾವುದೇ ಸೇವೆಗಳು ಸ್ಥಗಿತಗೊಂಡಿಲ್ಲ, ಆದರೆ ತಪ್ಪಾದ ರಿಸೋರ್ಸ್ ಹೆಸರು ಅಥವಾ ದೋಷಪೂರಿತ AI ಪ್ರಾಂಪ್ಟ್ನಿಂದಾಗಿ ನಿರ್ಣಾಯಕ ಮೂಲಸೌಕರ್ಯಗಳನ್ನು ಅಳಿಸಿಹಾಕುವ ಸಾಧ್ಯತೆಯಿತ್ತು ಎಂಬುದನ್ನು ಈ ಎಚ್ಚರಿಕೆಯು ಎತ್ತಿ ತೋರಿಸಿತು.
ಪತ್ತೆ ಮಾಡುವುದು ಎಂದರೆ ತಡೆಗಟ್ಟುವುದು ಎಂದಲ್ಲ ಎಂದು ತಂಡವು ಅರಿತುಕೊಂಡಿತು. ಒಂದು ವೇಳೆ AI ತಪ್ಪಾದ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಅಳಿಸಿರಿದ್ದರೆ, ದೊಡ್ಡ ವಿಪತ್ತು ಸಂಭವಿಸುತ್ತಿತ್ತು.
ಹಳೆಯ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಮಾದರಿ ಏಕೆ ವಿಫಲವಾಯಿತು
ಸಂಸ್ಥೆಯ ಹಿಂದಿನ ವಿಧಾನವು ಮಲ್ಟಿ-ಫ್ಯಾಕ್ಟರ್ ಅಥೆಂಟಿಕೇಶನ್ (MFA) ಮೂಲಕ ರಕ್ಷಿಸಲ್ಪಟ್ಟ ಅಲ್ಪಾವಧಿಯ ಸೆಷನ್ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿತ್ತು. ಸಿದ್ಧಾಂತದ ಪ್ರಕಾರ, ಒಬ್ಬ ಡೆವಲಪರ್ ಒಂದು ಸೆಷನ್ ಅನ್ನು ವಿನಂತಿಸುತ್ತಾರೆ, ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅವಧಿ ಮುಗಿಯುತ್ತವೆ. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಒಮ್ಮೆ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಸೆಷನ್ ಪ್ರಾರಂಭವಾದರೆ, ಅದು ಯಂತ್ರದ ಅಪ್ಟೈಮ್ (uptime) ವರೆಗೆ ಉಳಿಯುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಪ್ರಕ್ರಿಯೆ—ಟೆಸ್ಟ್ ಸೂಟ್ಗಳು, ಬ್ಯಾಕ್ಗ್ರೌಂಡ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಮತ್ತು ಈಗ AI ಏಜೆಂಟ್ಗಳು—ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಆ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತಿದ್ದವು.
ಆ “ambient credential” ಸಮಸ್ಯೆಯು ಪ್ರೊಡಕ್ಷನ್ IAM ರೋಲ್ ಅನ್ನು ಡೆವಲಪರ್ನ ವರ್ಕ್ಸ್ಟೇಷನ್ನಲ್ಲೇ ಅಳವಡಿಸಿತ್ತು. ಅದೇ ಶೆಲ್ನಲ್ಲಿ ಸಬ್ಪ್ರೊಸೆಸ್ ಆಗಿ ಚಲಿಸುತ್ತಿದ್ದ AI ಏಜೆಂಟ್, ಅದೇ ಅನುಮತಿಗಳನ್ನು ಪಡೆದುಕೊಂಡಿತು ಮತ್ತು ಮನುಷ್ಯನಂತೆಯೇ ಪ್ರೊಡಕ್ಷನ್ ರಿಸೋರ್ಸ್ಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬಲ್ಲದು.
ಅಕ್ಸೆಸ್ ಬ್ರೋಕರ್: ಒಂದು ಹೊಸ ಕಾವಲುಗಾರ
ಆಂಬಿಯೆಂಟ್ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳ ಸರಪಳಿಯನ್ನು ಮುರಿಯಲು, ತಂಡವು ಪ್ರೊಡಕ್ಷನ್ ರೋಲ್ಗಳನ್ನು ಯಾರು ವಹಿಸಿಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನು ಮರು-ರೂಪಕಗೊಳಿಸಿತು (re-architected). ಯಾವುದೇ ಡೆವಲಪರ್ ಗುರುತನ್ನು ನೇರವಾಗಿ ಅಧಿಕಾರವಿರುವ ರೋಲ್ ವಹಿಸಿಕೊಳ್ಳಲು ಬಿಡುವ ಬದಲು, ಅವರು ಒಂದು ಏಕೈಕ, ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಯಂತ್ರಿಸಲ್ಪಡುವ ಘಟಕವನ್ನು ಪರಿಚಯಿಸಿದರು: ಅಂತರಾತ್ಮೀಯ ಅಕ್ಸೆಸ್ ಬ್ರೋಕರ್ (internal access broker).
ವಿನಂತಿ ಹರಿವು (Request flow)
- Web portal – ಎಂಜಿನಿಯರ್ ಸೆಲ್ಫ್-ಸರ್ವಿಸ್ ಪೋರ್ಟಲ್ ಅನ್ನು ತೆರೆಯುತ್ತಾರೆ, ಅಗತ್ಯವಿರುವ ಪ್ರವೇಶ ಮಟ್ಟವನ್ನು (read-only, developer, ಅಥವಾ administrator) ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಕಾರಣವನ್ನು ನೀಡುತ್ತಾರೆ.
- Slack approval – ವಿನಂತಿಯು ಮೀಸಲಾದ Slack ಚಾನಲ್ಗೆ ಪೋಸ್ಟ್ ಆಗುತ್ತದೆ, ಅಲ್ಲಿ ನಿಗದಿತ ಅನುಮೋದಕರು (approver) ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿಯನ್ನು ನೀಡಬೇಕು.
Slack ಹಂತವು AI ಏಜೆಂಟ್ ಚಲಿಸುವ ಟರ್ಮಿನಲ್ನಿಂದ ವಿಭಿನ್ನವಾದ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲಿ ಎರಡನೇ ಫ್ಯಾಕ್ಟರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಅನುಮೋದನೆಯು ಪ್ರತ್ಯೇಕ UI ನಲ್ಲಿ ನಡೆಯಬೇಕಾಗಿರುವುದರಿಂದ, ಸ್ವಾಯತ್ತ ಸ್ಕ್ರಿಪ್ಟ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಈ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಹಂತದ ಪ್ರವೇಶ (Tiered access)
- Read-only – ಬಳಕೆದಾರರು ರಿಸೋರ್ಸ್ಗಳು ಮತ್ತು ಲಾಗ್ಗಳನ್ನು ನೋಡಬಹುದು ಆದರೆ ಏನನ್ನೂ ಮಾರ್ಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
- Developer – ಬೆಂಬಲ ಕಾರ್ಯಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಬದಲಾವಣೆಗಳಿಗಾಗಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆ; ಈ ಹಂತವು ಸ್ಟ್ಯಾಕ್ ಅಳಿಸುವಿಕೆ ಅಥವಾ ಗ್ರಾಹಕರ ಡೇಟಾಕ್ಕೆ ನೇರ ಪ್ರವೇಶದಂತಹ ವಿನಾಶಕಾರಿ ಕ್ರಮಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
- Administrator – ಪೂರ್ಣ ಅಧಿಕಾರಗಳು, ತುರ್ತು ಹಸ್ತಕ್ಷೇಪಗಳಿಗಾಗಿ ಮೀಸಲಿಡಲಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಪರಿಶೀಲನೆಯ ನಂತರವಷ್ಟೇ ನೀಡಲಾಗುತ್ತದೆ.
ಎಲ್ಲಾ ಪ್ರೊಡಕ್ಷನ್ ಪ್ರವೇಶವನ್ನು ಬ್ರೋಕರ್ ಮೂಲಕ ಕಳುಹಿಸುವ ಮೂಲಕ, ತಂಡವು ಅಧಿಕಾರವಿರುವ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ಪ್ರತಿಯೊಂದು ಲ್ಯಾಪ್ಟಾಪ್ಗೆ ಹರಡುವ ಬದಲು, ಅಪಾಯವನ್ನು ಒಂದೇ, ಬಲವಾಗಿ ರಕ್ಷಿಸಲ್ಪಟ್ಟ ಸೇವೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿತು.
ಬ್ರೋಕರ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ತಡೆಯುತ್ತದೆ
AI ಏಜೆಂಟ್ಗಳು ಮೌನವಾಗಿ ಬಳಸಿಕೊಳ್ಳಬಹುದಾದ ambient credentials ಅನ್ನು ತಡೆಯುವುದು ಬ್ರೋಕರ್ನ ಪ್ರಾಥಮಿಕ ಉದ್ದೇಶವಾಗಿದೆ. ಮನುಷ್ಯನು ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸಿದರೂ ಸಹ, ಆ ಅನುಮೋದನೆಯು ಒಂದು ಪ್ರಜ್ಞಾಪೂರ್ವಕ ನಿರ್ಧಾರವಾಗಿರುತ್ತದೆ; AI ಆ ಹಂತವನ್ನು ಸೃಷ್ಟಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ:
- ಅನಿರೀಕ್ಷಿತ ಅಳಿಸುವಿಕೆಗಳು (Unintended deletions) – ಮನುಷ್ಯನು ಸೆಷನ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅಧಿಕೃತಗೊಳಿಸದ ಹೊರತು AI ಇನ್ನು ಮುಂದೆ ಡಿಲೀಟ್ ಕಮಾಂಡ್ ನೀಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
- ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಹರಡುವಿಕೆ (Credential sprawl) – ಪ್ರೊಡಕ್ಷನ್ ಕೀಗಳು ಇನ್ನು ಮುಂದೆ ಡೆವಲಪರ್ ಯಂತ್ರಗಳಲ್ಲಿ ಇರುವುದಿಲ್ಲ, ಇದರಿಂದ ದುರುದ್ದೇಶಪೂರಿತ ಒಳಬಂದವರು ಮತ್ತು ಲ್ಯಾಪ್ಟಾಪ್ ಅನ್ನು ಹ್ಯಾಕ್ ಮಾಡಬಹುದಾದ ಬಾಹ್ಯ ವ್ಯಕ್ತಿಗಳ ದಾಳಿಯ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ಈ ವ್ಯವಸ್ಥೆಯು ಮಾನವ ತಪ್ಪುಗಳನ್ನು ಹೋಗಲಾಡಿಸುವುದಿಲ್ಲ ಎಂದು ತಂಡವು ಒತ್ತಿಹೇಳುತ್ತದೆ; ತಪ್ಪು ಅನುಮೋದನೆಯು ಇನ್ನೂ ಹಾನಿಯನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಆದಾಗ್ಯೂ, ಇದು ಯಾವುದೇ ಮಾನವ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಸ್ವಾಯತ್ತ ಕೋಡ್ ಪ್ರೊಡಕ್ಷನ್ ರಿಸೋರ್ಸ್ಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ “ಮೌನ” ಅಪಾಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ತಗೆಅವೈ (Takeaway)
AI ಏಜೆಂಟ್ಗಳು ಮಾನವ ಇಂಜಿನಿಯರ್ಗಳಂತೆಯೇ ಅಡೆತಡೆಯಿಲ್ಲದ ಪ್ರವೇಶಾಧಿಕಾರಗಳನ್ನು ಪಡೆದಾಗ, ಅವರು ಪ್ರೊಡಕ್ಷನ್ ಅನ್ನು ಹಾಳುಮಾಡುವ ಶಕ್ತಿಯನ್ನು ಪಡೆಯುತ್ತಾರೆ—ಅದು ಕೂಡ ಯಾರೂ ಗಮನಿಸದೆಯೇ ಆಗಬಹುದು. ಪ್ರತ್ಯೇಕ ಮಾನವ ಅನುಮೋದನಾ ಚಾನಲ್ ಅನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸುವ ಬ್ರೋಕರ್ ಮೂಲಕ ಪ್ರಿವileged್ ಆಕ್ಸೆಸ್ ಅನ್ನು ಕೇಂದ್ರೀಕರಿಸುವ ಮೂಲಕ, ಒಂದು ತಂಡವು ಸ್ವಾಯತ್ತ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಮೌನವಾಗಿ ಅನಾಹುತಗಳನ್ನು ಉಂಟುಮಾಡುವುದನ್ನು ತಡೆಯಬಹುದು, ಆದರೂ ಮಾನವನ ತಪ್ಪುಗಳು ತೊಂದರೆ ಉಂಟುಮಾಡಬಹುದು. ನಿಜವಾದ ಭದ್ರತಾ ಯಶಸ್ಸು ಎಂದರೆ ಅಂಬಿಯೆಂಟ್ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು ನಿರ್ಮೂಲನೆ ಮಾಡುವುದು ಹೊರತು, ಪ್ರತಿಯೊಂದು ವೈಯಕ್ತಿಕ ನಿರ್ಧಾರವನ್ನು ನಿಯಂತ್ರಿಸುವುದಲ್ಲ.