ಜುಲೈ 19, 2019 ರಂದು, ಕ್ಯಾಪಿಟಲ್ ಒನ್ ಪ್ರತಿ ಆಧುನಿಕ ಕಂಪನಿಯು ಭಯಪಡುವ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸಿದೆ - ಡೇಟಾ ಉಲ್ಲಂಘನೆ ಸಂಭವಿಸಿದೆ. ಇದು 106 ದಶಲಕ್ಷಕ್ಕೂ ಹೆಚ್ಚು ಜನರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿತು. 140 US ಸಾಮಾಜಿಕ ಭದ್ರತೆ ಸಂಖ್ಯೆಗಳು, ಒಂದು ಮಿಲಿಯನ್ ಕೆನಡಾದ ಸಾಮಾಜಿಕ ಭದ್ರತೆ ಸಂಖ್ಯೆಗಳು. 000 ಬ್ಯಾಂಕ್ ಖಾತೆಗಳು. ಅಹಿತಕರ, ನೀವು ಒಪ್ಪುವುದಿಲ್ಲವೇ?
ದುರದೃಷ್ಟವಶಾತ್, ಜುಲೈ 19 ರಂದು ಹ್ಯಾಕ್ ಸಂಭವಿಸಲಿಲ್ಲ. ಅದು ಬದಲಾದಂತೆ, ಪೈಜ್ ಥಾಂಪ್ಸನ್, a.k.a. ಅನಿಯಮಿತ, ಇದನ್ನು ಮಾರ್ಚ್ 22 ಮತ್ತು ಮಾರ್ಚ್ 23, 2019 ರ ನಡುವೆ ಒಪ್ಪಿಸಲಾಗಿದೆ. ಅದು ಸುಮಾರು ನಾಲ್ಕು ತಿಂಗಳ ಹಿಂದೆ. ವಾಸ್ತವವಾಗಿ, ಯಾವುದೋ ಸಂಭವಿಸಿದೆ ಎಂದು ಕ್ಯಾಪಿಟಲ್ ಒನ್ ಪತ್ತೆಹಚ್ಚಲು ಹೊರಗಿನ ಸಲಹೆಗಾರರ ಸಹಾಯದಿಂದ ಮಾತ್ರ ಸಾಧ್ಯವಾಯಿತು.
ಮಾಜಿ ಅಮೆಜಾನ್ ಉದ್ಯೋಗಿಯನ್ನು ಬಂಧಿಸಲಾಯಿತು ಮತ್ತು $250 ದಂಡ ಮತ್ತು ಐದು ವರ್ಷಗಳ ಜೈಲು ಶಿಕ್ಷೆಯನ್ನು ಎದುರಿಸುತ್ತಾನೆ... ಆದರೆ ಇನ್ನೂ ಬಹಳಷ್ಟು ನಕಾರಾತ್ಮಕತೆ ಉಳಿದಿದೆ. ಏಕೆ? ಏಕೆಂದರೆ ಹ್ಯಾಕ್‌ಗಳಿಂದ ಬಳಲುತ್ತಿರುವ ಅನೇಕ ಕಂಪನಿಗಳು ಸೈಬರ್‌ಕ್ರೈಮ್‌ಗಳ ಹೆಚ್ಚಳದ ಮಧ್ಯೆ ತಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಲಪಡಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ನುಣುಚಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿವೆ.
ಹೇಗಾದರೂ, ನೀವು ಈ ಕಥೆಯನ್ನು ಸುಲಭವಾಗಿ ಗೂಗಲ್ ಮಾಡಬಹುದು. ನಾವು ನಾಟಕಕ್ಕೆ ಹೋಗುವುದಿಲ್ಲ, ಆದರೆ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ ತಾಂತ್ರಿಕ ವಿಷಯದ ಬದಿ.
ಮೊದಲನೆಯದಾಗಿ, ಏನಾಯಿತು?
ಕ್ಯಾಪಿಟಲ್ ಒನ್ ಸುಮಾರು 700 S3 ಬಕೆಟ್‌ಗಳನ್ನು ಓಡಿಸುತ್ತಿತ್ತು, ಅದನ್ನು ಪೈಜ್ ಥಾಂಪ್ಸನ್ ನಕಲು ಮಾಡಿದರು ಮತ್ತು ಸಿಫನ್ ಮಾಡಿದರು.
ಎರಡನೆಯದಾಗಿ, ಇದು ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ S3 ಬಕೆಟ್ ನೀತಿಯ ಮತ್ತೊಂದು ಪ್ರಕರಣವೇ?
ಇಲ್ಲ, ಈ ಬಾರಿ ಅಲ್ಲ. ಇಲ್ಲಿ ಅವಳು ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಫೈರ್‌ವಾಲ್‌ನೊಂದಿಗೆ ಸರ್ವರ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆದರು ಮತ್ತು ಅಲ್ಲಿಂದ ಸಂಪೂರ್ಣ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಡೆಸಿದರು.
ನಿರೀಕ್ಷಿಸಿ, ಅದು ಹೇಗೆ ಸಾಧ್ಯ?
ಸರಿ, ನಮ್ಮಲ್ಲಿ ಹೆಚ್ಚಿನ ವಿವರಗಳಿಲ್ಲದಿದ್ದರೂ ಸರ್ವರ್‌ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸೋಣ. ಇದು "ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಫೈರ್‌ವಾಲ್" ಮೂಲಕ ಸಂಭವಿಸಿದೆ ಎಂದು ನಮಗೆ ತಿಳಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ತಪ್ಪಾದ ಭದ್ರತಾ ಗುಂಪಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಅಥವಾ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲ್ (ಇಂಪರ್ವಾ), ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಫೈರ್‌ವಾಲ್ (ಐಪಿಟೇಬಲ್ಸ್, ಯುಎಫ್‌ಡಬ್ಲ್ಯೂ, ಶೋರ್‌ವಾಲ್, ಇತ್ಯಾದಿ) ಕಾನ್ಫಿಗರೇಶನ್‌ನಂತಹ ಸರಳವಾದದ್ದು. ಕ್ಯಾಪಿಟಲ್ ಒನ್ ಮಾತ್ರ ತನ್ನ ತಪ್ಪನ್ನು ಒಪ್ಪಿಕೊಂಡಿತು ಮತ್ತು ರಂಧ್ರವನ್ನು ಮುಚ್ಚಿದೆ ಎಂದು ಹೇಳಿದರು.
ಕ್ಯಾಪಿಟಲ್ ಒನ್ ಆರಂಭದಲ್ಲಿ ಫೈರ್‌ವಾಲ್ ದುರ್ಬಲತೆಯನ್ನು ಗಮನಿಸಲಿಲ್ಲ ಆದರೆ ಅದರ ಬಗ್ಗೆ ತಿಳಿದ ನಂತರ ತ್ವರಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು ಎಂದು ಸ್ಟೋನ್ ಹೇಳಿದರು. ಹ್ಯಾಕರ್ ಸಾರ್ವಜನಿಕ ಡೊಮೇನ್‌ನಲ್ಲಿ ಪ್ರಮುಖ ಗುರುತಿಸುವ ಮಾಹಿತಿಯನ್ನು ಬಿಟ್ಟಿದ್ದಾನೆ ಎಂಬ ಅಂಶದಿಂದ ಇದು ಖಂಡಿತವಾಗಿಯೂ ಸಹಾಯ ಮಾಡಿತು ಎಂದು ಸ್ಟೋನ್ ಹೇಳಿದರು.
ನಾವು ಈ ಭಾಗಕ್ಕೆ ಏಕೆ ಆಳವಾಗಿ ಹೋಗುತ್ತಿಲ್ಲ ಎಂದು ನೀವು ಆಶ್ಚರ್ಯ ಪಡುತ್ತಿದ್ದರೆ, ಸೀಮಿತ ಮಾಹಿತಿಯಿಂದಾಗಿ ನಾವು ಕೇವಲ ಊಹೆ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ಕ್ಯಾಪಿಟಲ್ ಒನ್ ಬಿಟ್ಟ ರಂಧ್ರವನ್ನು ಹ್ಯಾಕ್ ಅವಲಂಬಿಸಿದೆ ಎಂದು ಇದು ಅರ್ಥವಿಲ್ಲ. ಮತ್ತು ಅವರು ನಮಗೆ ಹೆಚ್ಚಿನದನ್ನು ತಿಳಿಸದ ಹೊರತು, ಕ್ಯಾಪಿಟಲ್ ಒನ್ ತಮ್ಮ ಸರ್ವರ್ ಅನ್ನು ತೆರೆದಿರುವ ಎಲ್ಲಾ ಸಂಭಾವ್ಯ ಮಾರ್ಗಗಳನ್ನು ನಾವು ಪಟ್ಟಿ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಯಾರಾದರೂ ಈ ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಬಳಸಬಹುದಾದ ಎಲ್ಲಾ ಸಂಭಾವ್ಯ ವಿಧಾನಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತೇವೆ. ಈ ನ್ಯೂನತೆಗಳು ಮತ್ತು ತಂತ್ರಗಳು ಹುಚ್ಚುಚ್ಚಾಗಿ ಸ್ಟುಪಿಡ್ ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ ನಂಬಲಾಗದಷ್ಟು ಸಂಕೀರ್ಣ ಮಾದರಿಗಳವರೆಗೆ ಇರಬಹುದು. ಸಾಧ್ಯತೆಗಳ ವ್ಯಾಪ್ತಿಯನ್ನು ನೀಡಿದರೆ, ಇದು ಯಾವುದೇ ನಿಜವಾದ ತೀರ್ಮಾನವಿಲ್ಲದೆ ದೀರ್ಘ ಸಾಹಸವಾಗಿ ಪರಿಣಮಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಸತ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ಭಾಗವನ್ನು ವಿಶ್ಲೇಷಿಸುವತ್ತ ಗಮನಹರಿಸೋಣ.
ಆದ್ದರಿಂದ ಮೊದಲ ಟೇಕ್‌ಅವೇ: ನಿಮ್ಮ ಫೈರ್‌ವಾಲ್‌ಗಳು ಏನನ್ನು ಅನುಮತಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.
ತೆರೆಯಬೇಕಾದದ್ದು ಮಾತ್ರ ತೆರೆಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀತಿ ಅಥವಾ ಸರಿಯಾದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಥಾಪಿಸಿ. ನೀವು ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್‌ಗಳು ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ACL ಗಳಂತಹ AWS ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನಿಸ್ಸಂಶಯವಾಗಿ ಲೆಕ್ಕಪರಿಶೋಧನೆಯ ಪರಿಶೀಲನಾಪಟ್ಟಿ ದೀರ್ಘವಾಗಿರುತ್ತದೆ... ಆದರೆ ಹಲವು ಸಂಪನ್ಮೂಲಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲ್ಪಟ್ಟಂತೆ (ಅಂದರೆ CloudFormation), ಅವುಗಳ ಆಡಿಟಿಂಗ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಸಹ ಸಾಧ್ಯವಿದೆ. ಇದು ನ್ಯೂನತೆಗಳಿಗಾಗಿ ಹೊಸ ವಸ್ತುಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಹೋಮ್‌ಮೇಡ್ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿರಲಿ ಅಥವಾ CI/CD ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭದ್ರತಾ ಲೆಕ್ಕಪರಿಶೋಧನೆಯಂತಹದ್ದೇ ಆಗಿರಲಿ... ಇದನ್ನು ತಪ್ಪಿಸಲು ಹಲವು ಸುಲಭ ಆಯ್ಕೆಗಳಿವೆ.
ಕಥೆಯ "ತಮಾಷೆಯ" ಭಾಗವೆಂದರೆ ಕ್ಯಾಪಿಟಲ್ ಒನ್ ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ರಂಧ್ರವನ್ನು ಪ್ಲಗ್ ಮಾಡಿದ್ದರೆ ... ಏನೂ ಆಗುತ್ತಿರಲಿಲ್ಲ. ಮತ್ತು ಆದ್ದರಿಂದ, ನಾನೂ, ನಿಜವಾಗಿಯೂ ಏನಾದರೂ ಹೇಗೆ ಎಂದು ನೋಡಲು ಯಾವಾಗಲೂ ಆಘಾತಕಾರಿಯಾಗಿದೆ ಬಹಳ ಸರಳ ಕಂಪನಿಯನ್ನು ಹ್ಯಾಕ್ ಮಾಡಲು ಏಕೈಕ ಕಾರಣವಾಗುತ್ತದೆ. ಅದರಲ್ಲೂ ಕ್ಯಾಪಿಟಲ್ ಒಂದರಷ್ಟೇ ದೊಡ್ಡದು.
ಹಾಗಾದರೆ, ಒಳಗೆ ಹ್ಯಾಕರ್ - ಮುಂದೆ ಏನಾಯಿತು?
ಸರಿ, EC2 ನಿದರ್ಶನಕ್ಕೆ ಪ್ರವೇಶಿಸಿದ ನಂತರ... ಬಹಳಷ್ಟು ತಪ್ಪಾಗಬಹುದು. ನೀವು ಯಾರನ್ನಾದರೂ ಅಷ್ಟು ದೂರ ಹೋಗಲು ಬಿಟ್ಟರೆ ನೀವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಚಾಕುವಿನ ಅಂಚಿನಲ್ಲಿ ನಡೆಯುತ್ತಿದ್ದೀರಿ. ಆದರೆ ಅದು S3 ಬಕೆಟ್‌ಗಳಿಗೆ ಹೇಗೆ ಬಂತು? ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, IAM ಪಾತ್ರಗಳನ್ನು ಚರ್ಚಿಸೋಣ.
ಆದ್ದರಿಂದ, AWS ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಒಂದು ಮಾರ್ಗವೆಂದರೆ ಬಳಕೆದಾರರಾಗಿರುವುದು. ಸರಿ, ಇದು ಬಹಳ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಆದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳಂತಹ ಇತರ AWS ಸೇವೆಗಳನ್ನು ನಿಮ್ಮ S3 ಬಕೆಟ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡಲು ನೀವು ಬಯಸಿದರೆ ಏನು? ಅದಕ್ಕಾಗಿಯೇ IAM ಪಾತ್ರಗಳು. ಅವು ಎರಡು ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ:
- ನಂಬಿಕೆ ನೀತಿ - ಯಾವ ಸೇವೆಗಳು ಅಥವಾ ಜನರು ಈ ಪಾತ್ರವನ್ನು ಬಳಸಬಹುದು?
- ಅನುಮತಿಗಳ ನೀತಿ - ಈ ಪಾತ್ರವು ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ?
ಉದಾಹರಣೆಗೆ, ನೀವು S2 ಬಕೆಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು EC3 ನಿದರ್ಶನಗಳನ್ನು ಅನುಮತಿಸುವ IAM ಪಾತ್ರವನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೀರಿ: ಮೊದಲನೆಯದಾಗಿ, EC2 (ಸಂಪೂರ್ಣ ಸೇವೆ) ಅಥವಾ ನಿರ್ದಿಷ್ಟ ನಿದರ್ಶನಗಳು ಪಾತ್ರವನ್ನು "ಸ್ವಾಧೀನಪಡಿಸಿಕೊಳ್ಳಬಹುದು" ಎಂಬ ಟ್ರಸ್ಟ್ ನೀತಿಯನ್ನು ಹೊಂದಲು ಪಾತ್ರವನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ. ಪಾತ್ರವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಎಂದರೆ ಅವರು ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಪಾತ್ರದ ಅನುಮತಿಗಳನ್ನು ಬಳಸಬಹುದು. ಎರಡನೆಯದಾಗಿ, ಅನುಮತಿಗಳ ನೀತಿಯು "ಪಾತ್ರವನ್ನು ವಹಿಸಿಕೊಂಡಿರುವ" ಸೇವೆ/ವ್ಯಕ್ತಿ/ಸಂಪನ್ಮೂಲವನ್ನು S3 ನಲ್ಲಿ ಏನನ್ನೂ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಅದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಬಕೆಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತಿರಲಿ... ಅಥವಾ ಕ್ಯಾಪಿಟಲ್ ಒನ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ 700 ಕ್ಕಿಂತ ಹೆಚ್ಚು.
ಒಮ್ಮೆ ನೀವು IAM ಪಾತ್ರದೊಂದಿಗೆ EC2 ನಿದರ್ಶನದಲ್ಲಿದ್ದರೆ, ನೀವು ಹಲವಾರು ವಿಧಗಳಲ್ಲಿ ರುಜುವಾತುಗಳನ್ನು ಪಡೆಯಬಹುದು:
- ನೀವು ನಿದರ್ಶನ ಮೆಟಾಡೇಟಾವನ್ನು ಇಲ್ಲಿ ವಿನಂತಿಸಬಹುದು
http://169.254.169.254/latest/meta-dataಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ನೀವು ಈ ವಿಳಾಸದಲ್ಲಿ ಯಾವುದೇ ಪ್ರವೇಶ ಕೀಗಳೊಂದಿಗೆ IAM ಪಾತ್ರವನ್ನು ಕಾಣಬಹುದು. ಸಹಜವಾಗಿ, ನೀವು ಒಂದು ನಿದರ್ಶನದಲ್ಲಿದ್ದರೆ ಮಾತ್ರ.
- AWS CLI ಬಳಸಿ...
AWS CLI ಅನ್ನು ಸ್ಥಾಪಿಸಿದರೆ, ಅದು IAM ಪಾತ್ರಗಳಿಂದ ರುಜುವಾತುಗಳೊಂದಿಗೆ ಲೋಡ್ ಆಗುತ್ತದೆ. ನಿದರ್ಶನದ ಮೂಲಕ ಕೆಲಸ ಮಾಡುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. ಸಹಜವಾಗಿ, ಅವರ ಟ್ರಸ್ಟ್ ನೀತಿ ತೆರೆದಿದ್ದರೆ, ಪೈಜ್ ನೇರವಾಗಿ ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದು.
ಆದ್ದರಿಂದ IAM ಪಾತ್ರಗಳ ಮೂಲತತ್ವವೆಂದರೆ ಅವರು ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಇತರ ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ ನಿಮ್ಮ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುಮತಿಸುತ್ತಾರೆ.
ಈಗ ನೀವು IAM ನ ಪಾತ್ರಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ, ಪೈಜ್ ಥಾಂಪ್ಸನ್ ಏನು ಮಾಡಿದರು ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡಬಹುದು:
- ಅವಳು ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿನ ರಂಧ್ರದ ಮೂಲಕ ಸರ್ವರ್‌ಗೆ (EC2 ನಿದರ್ಶನ) ಪ್ರವೇಶವನ್ನು ಪಡೆದಳು
ಇದು ಭದ್ರತಾ ಗುಂಪುಗಳು/ACL ಗಳು ಅಥವಾ ಅವರ ಸ್ವಂತ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲ್‌ಗಳು ಆಗಿರಲಿ, ಅಧಿಕೃತ ದಾಖಲೆಗಳಲ್ಲಿ ಹೇಳಿರುವಂತೆ ರಂಧ್ರವನ್ನು ಪ್ಲಗ್ ಮಾಡುವುದು ಬಹುಶಃ ತುಂಬಾ ಸುಲಭ.
- ಒಮ್ಮೆ ಸರ್ವರ್‌ನಲ್ಲಿ, ಅವಳು ಸ್ವತಃ ಸರ್ವರ್‌ನಂತೆ "ಇರುವಂತೆ" ವರ್ತಿಸಲು ಸಾಧ್ಯವಾಯಿತು
- IAM ಸರ್ವರ್ ಪಾತ್ರವು ಈ 3+ ಬಕೆಟ್‌ಗಳಿಗೆ S700 ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸಿದ ಕಾರಣ, ಅದು ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಯಿತು
ಆ ಕ್ಷಣದಿಂದ, ಅವಳು ಮಾಡಬೇಕಾಗಿರುವುದು ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುವುದು List Bucketsತದನಂತರ ಆಜ್ಞೆ Sync AWS CLI ನಿಂದ...
. ಅಂತಹ ಹಾನಿಯನ್ನು ತಡೆಗಟ್ಟುವುದು ಏಕೆ ಕಂಪನಿಗಳು ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯ ರಕ್ಷಣೆ, DevOps ಮತ್ತು ಭದ್ರತಾ ತಜ್ಞರಲ್ಲಿ ಹೆಚ್ಚು ಹೂಡಿಕೆ ಮಾಡುತ್ತವೆ. ಮತ್ತು ಕ್ಲೌಡ್‌ಗೆ ಎಷ್ಟು ಮೌಲ್ಯಯುತ ಮತ್ತು ವೆಚ್ಚ-ಪರಿಣಾಮಕಾರಿ ಚಲಿಸುತ್ತಿದೆ? ಎಷ್ಟರಮಟ್ಟಿಗೆ ಎಂದರೆ ಹೆಚ್ಚು ಹೆಚ್ಚು ಸೈಬರ್‌ ಸೆಕ್ಯುರಿಟಿ ಸವಾಲುಗಳ ನಡುವೆಯೂ !
ಕಥೆಯ ನೈತಿಕತೆ: ನಿಮ್ಮ ಸುರಕ್ಷತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ; ನಿಯಮಿತ ಲೆಕ್ಕಪರಿಶೋಧನೆಗಳನ್ನು ನಡೆಸುವುದು; ಭದ್ರತಾ ನೀತಿಗಳಿಗಾಗಿ ಕನಿಷ್ಠ ಸವಲತ್ತುಗಳ ತತ್ವವನ್ನು ಗೌರವಿಸಿ.
( ನೀವು ಸಂಪೂರ್ಣ ಕಾನೂನು ವರದಿಯನ್ನು ವೀಕ್ಷಿಸಬಹುದು).
ಮೂಲ: www.habr.com