DigiCert ಡೇಟಾ ಉಲ್ಲಂಘನೆಯ ವಿವರಣೆ: ಆರ್ಕೈವ್ ಮಾಡಲಾದ ಸಿಸ್ಟಮ್ ಗುರುತಿನ ದಾಖಲೆಗಳನ್ನು ಹೇಗೆ ಬಹಿರಂಗಪಡಿಸಿತು, ಮತ್ತು ಇದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬೇಕು

ಇಲ್ಲಿ ಯಾರೂ ಬಾಗಿಲು ಮುರಿದು ಒಳನುಗ್ಗಲಿಲ್ಲ. ಒಂದು ಖಾಸಗಿ ಕೋಣೆಯು ಸದ್ದಿಲ್ಲದೆ ರಸ್ತೆಯಿಂದ ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಯಿತು, ಅಪರಿಚಿತರು ಮುಂಭಾಗದ ಡೆಸ್ಕ್‌ನಲ್ಲಿ ತಾವೇ ಸೈನ್-ಇನ್ ಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಯಿತು, ಮತ್ತು ಅನುಮತಿಗಳಲ್ಲಿದ್ದ ದೋಷವು ಅವರು ಒಳಗೆ ಸಂಗ್ರಹಿಸಲಾಗಿದ್ದ ಹಳೆಯ ಫೈಲ್‌ಗಳನ್ನು ಓದಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ಇಂದು ನವೆಂಬರ್ 6, 2026, ಮತ್ತು ಈ ವಿಷಯವು ಇದೀಗ ಮಹತ್ವದ್ದಾಗಿದೆ ಏಕೆಂದರೆ ಅತ್ಯಂತ ಪ್ರಸಿದ್ಧ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರಗಳಲ್ಲಿ (certificate authorities) ಒಂದಾದ DigiCert, ಆರ್ಕೈವ್ ಮಾಡಲಾದ ದಾಖಲೆಗಳ ಉಲ್ಲಂಘನೆಯ ಬಗ್ಗೆ ಗ್ರಾಹಕರಿಗೆ ತಿಳಿಸುತ್ತಿದೆ. ಆ ದಾಖಲೆಗಳಲ್ಲಿ ವ್ಯಾಪಾರ ಸಂಪರ್ಕ ವಿವರಗಳು ಮತ್ತು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಪಾಸ್‌ಪೋರ್ಟ್‌ಗಳು ಹಾಗೂ ಚಾಲನಾ ಪರವಾನಗಿಗಳಂತಹ ಗುರುತಿನ ದಾಖಲೆಗಳು ಸೇರಿವೆ. ಕಂಪನಿಯ ಫಾಲೋ-ಅಪ್ ಕೆಲಸಗಳ ಪಟ್ಟಿಯು ಇಂದಿನ ಗಡುವನ್ನು ಸಹ ಹೊಂದಿದೆ.

ನೀವು DigiCert ಗ್ರಾಹಕರಾಗಿದ್ದರೆ, ನೀವು ಮಾಡಬೇಕಾದ ಪ್ರಾಯೋಗಿಕ ಕೆಲಸಗಳ ಸಣ್ಣ ಪಟ್ಟಿ ಇದೆ. ನೀವು ಅಲ್ಲದಿದ್ದರೂ ಸಹ, ಈ ಘಟನೆಯು ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದೇ ರೀತಿಯ ಮಾದರಿಯು ಯಾವುದೇ ಕಂಪನಿಯೊಳಗೆ ಇರಬಹುದು: ಹಳೆಯ ಆಂತರಿಕ ಟೂಲ್, ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆ ಮತ್ತು ವರ್ಷಗಳಿಂದ ಯಾರೂ ಪರಿಶೀಲಿಸದ ಊಹೆಗಳ ಒಂದು ಗುಂಪು.

ಈ ಮಾರ್ಗದರ್ಶಿಯು ಏನಾಯಿತು ಎಂಬುದನ್ನು ಸರಳ ಭಾಷೆಯಲ್ಲಿ ವಿವರಿಸುತ್ತದೆ, ತಿಳಿದಿರುವ ವಿಷಯಗಳನ್ನು ತಿಳಿಯದ ವಿಷಯಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ ಮತ್ತು ಎರಡು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳ ಮೂಲಕ ವಿವರಿಸುತ್ತದೆ. ಮೊದಲನೆಯದರಲ್ಲಿ, ರೋಹಿತ್ ಎಂಬ ಸೆಕ್ಯುರಿಟಿ ಲೀಡ್ ಗ್ರಾಹಕರ ಬಳಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತಾನೆ. ಎರಡನೆಯದರಲ್ಲಿ, ರೋಹಿತ್ ಕಂಪನಿಯ ಸ್ವಂತ ಆರ್ಕೈವ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಇದೇ ರೀತಿಯ ದೋಷಕ್ಕಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತಾನೆ.

ನಾವು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಒಂದು ಸಣ್ಣ ಶಬ್ದಕೋಶ

ಕೆಲವು ಪದಗಳು ಹೆಚ್ಚಾಗಿ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಸರಳ ಪದಗಳಲ್ಲಿ ಇಲ್ಲಿ ನೀಡಲಾಗಿದೆ.

• Certificate authority: ನೀವು ಯಾರೆಂದು ಪರಿಶೀಲಿಸುವ ಮತ್ತು ವೆಬ್‌ಸೈಟ್‌ಗಳು ಹಾಗೂ ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳು ತಮ್ಮ ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಡಿಜಿಟಲ್ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನೀಡುವ ಸಂಸ್ಥೆ.
• Identity verification: ಒಬ್ಬ ವ್ಯಕ್ತಿ ಅಥವಾ ಕಂಪನಿಯನ್ನು ನಂಬುವ ಮೊದಲು ಪೂರೈಕೆದಾರರು ನಿರ್ವಹಿಸುವ ಪರಿಶೀಲನೆಗಳು. ಇದು ದಾಖಲೆಗಳನ್ನು ಸಲ್ಲಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರಬಹುದು.
• VPN: ಒಂದು ಖಾಸಗಿ, ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಸಂಪರ್ಕ. ಅನೇಕ ಆಂತರಿಕ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಇದರ ಮೂಲಕ ಮಾತ್ರ ತಲುಪಬಹುದು.
• Multifactor authentication (MFA): ಪಾಸ್‌ವರ್ಡ್ ಜೊತೆಗೆ ಫೋನ್ ಅನುಮೋದನೆಯಂತಹ ಎರಡನೇ ಪುರಾವೆಯ ಅಗತ್ಯವಿರುವ ಲಾಗಿನ್.
• Authentication: ನೀವು ಯಾರೆಂದು ಸಾಬೀತುಪಡಿಸುವುದು.
• Authorisation: ನಿಮ್ಮ ಗುರುತು ತಿಳಿದ ನಂತರ ನೀವು ಏನನ್ನು ನೋಡಲು ಅಥವಾ ಮಾಡಲು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂದು ನಿರ್ಧರಿಸುವುದು.

ಕೊನೆಯ ಎರಡನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ. ಅವು ಈ ಕಥೆಯ ತಿರುಳು.

ಏನಾಯಿತು, ಕ್ರಮಾನುಗತವಾಗಿ

DigiCert ನ ಇನ್ಸಿಡೆಂಟ್ ವರದಿಯು ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರಗಳಿಗಾಗಿ ಇರುವ Mozilla ನ ಸಾರ್ವಜನಿಕ ಅನುಸರಣಾ ಟ್ರ್ಯಾಕರ್ ಮೂಲಕ ಪ್ರಕಟವಾಯಿತು. ಗ್ರಾಹಕರ ಅಧಿಸೂಚನೆಯೊಂದಿಗೆ, ಇದು ಈ ಕೆಳಗಿನ ಅನುಕ್ರಮವನ್ನು ನೀಡುತ್ತದೆ.

Date	What happened
4 February 2025	ಮೈಗ್ರೇಷನ್ ಒಂದರಿಂದಾಗಿ ಈ ಮೊದಲು VPN ನಿಂದ ನಿರ್ಬಂಧಿಸಲ್ಪಟ್ಟಿದ್ದ ಸಿಸ್ಟಮ್ ಬಾಹ್ಯವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದಾದಂತಾಯಿತು
June 2026	DigiCert ಅನಧಿಕೃತ ಖಾತೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿತು ಮತ್ತು ಆರಂಭದಲ್ಲಿ ಅವುಗಳು ಗ್ರಾಹಕರ ಮಾಹಿತಿಯನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ತೀರ್ಮಾನಿಸಿತು
Date not stated	ಅದರ ನಿರ್ವಹಣಾ ಭದ್ರತಾ ಸಂಶೋಧನಾ ಕಾರ್ಯಕ್ರಮದ ಮೂಲಕ ಬಂದ ವರದಿಯು ಬಾಹ್ಯ ಖಾತೆ ರಚನೆಯ ಬಗ್ಗೆ ಕಳವಳವನ್ನು ವ್ಯಕ್ತಪಡಿಸಿತು, ಮತ್ತು ನಂತರ ಭದ್ರತಾ ಪರಿಹಾರಗಳನ್ನು ಜಾರಿಗೆ ತರಲಾಯಿತು
27 June to 2 July 2026	ನಂತರ ದೃಢಪಡಿಸಲಾದ ಅನಧಿಕೃತ ಪ್ರವೇಶದ ಅವಧಿ
19 October 2026	ಹೆಚ್ಚಿನ ಪರಿಶೀಲನೆಯು ಗ್ರಾಹಕರ ದಾಖಲೆಗಳಿಗೆ ಅನಧಿಕೃತ ಪ್ರವೇಶ ನಡೆದಿದೆ ಎಂಬುದನ್ನು ದೃಢಪಡಿಸಿತು
6 November 2026	ಬಾಹ್ಯ-ಎಕ್ಸ್‌ಪೋಸರ್ ಆಡಿಟ್ ಮತ್ತು ಅಂತಿಮ ಖಾತೆ-ಎಚ್ಚರಿಕೆ ಪರಿಶೀಲನೆಗಾಗಿ ಪಟ್ಟಿ ಮಾಡಲಾದ ಗಡುವು

ಮೈಗ್ರೇಷನ್ ಮತ್ತು ಪತ್ತೆಹಚ್ಚುವಿಕೆಯ ನಡುವಿನ ಅಂತರವನ್ನು ಗಮನಿಸಿ. ಸಿಸ್ಟಮ್ ಫೆಬ್ರವರಿ 2025 ರಲ್ಲಿ ಬದಲಾಯಿತು, ಮತ್ತು ಖಾತೆಗಳು ಜೂನ್ 2026 ರಲ್ಲಿ ಪತ್ತೆಯಾದವು. ಖಾತೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮತ್ತು ಅವು ಏನನ್ನು ಓದಿವೆ ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸುವುದರ ನಡುವಿನ ಅಂತರವನ್ನೂ ಗಮನಿಸಿ. ಆ ಎರಡನೇ ಅಂತರವು ಇಡೀ ವರದಿಯ ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಪಾಠಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ಮೂರು ಸಣ್ಣ ವಿಷಯಗಳು ಹೇಗೆ ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾದವು

ಯಾವುದೇ ಒಂದೇ ವೈಫಲ್ಯವು ಈ ಕಥೆಯನ್ನು ಹೇಳುವುದಿಲ್ಲ. ಮೂರು ಪರಿಸ್ಥಿತಿಗಳು ಒಟ್ಟಾಗಿ ಸೇರಿದವು.

ಮೊದಲನೆಯದಾಗಿ, ನೆಟ್‌ವರ್ಕ್ ತಡೆಗೋಡೆ ಕಣ್ಮರೆಯಾಯಿತು. VPN ನಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದ್ದ ಸಿಸ್ಟಮ್ ಮೈಗ್ರೇಷನ್ ಸಮಯದಲ್ಲಿ ಹೊರಗಿನಿಂದ ಪ್ರವೇಶಿಸಬಹುದಾದಂತಾಯಿತು. ಜನರು ಸಾಮಾನ್ಯವಾಗಿ VPN ಅನ್ನು ಆಂತರಿಕ ಟೂಲ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿರಿಸುವ ವಿಷಯವೆಂದು ಪರಿಗಣಿಸುತ್ತಾರೆ. ಒಮ್ಮೆ ಅದು ಕಣ್ಮರೆಯಾದರೆ, ಅದರ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಊಹೆಯೂ ಬಹಿರಂಗಗೊಳ್ಳುತ್ತದೆ.

ಎರಡನೆಯದಾಗಿ, ಹೊರಗಿನವರು ಖಾತೆಗಳನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಸೆಲ್ಫ್-ರಿಜಿಸ್ಟ್ರೇಷನ್ ಸೌಲಭ್ಯವು ಹೊರಗಿನ ಜನರು ಖಾತೆಗಳನ್ನು ರಚಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ಸಿಬ್ಬಂದಿ ಬಳಸಬೇಕಾಗಿದ್ದ MFA ಈ ಖಾತೆಗಳಿಗೆ ಇರಲಿಲ್ಲ.

ಮೂರನೆಯದಾಗಿ, ಅನುಮತಿಯಲ್ಲಿದ್ದ ದೋಷವು ಉಳಿದದ್ದನ್ನು ಮಾಡಿತು. ಆ ಹೊಸ ಖಾತೆಗಳಿಗೆ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆಗಳು ಇರಲಿಲ್ಲ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಕಾಗದದ ಮೇಲೆ ಅವುಗಳಿಗೆ ಏನೂ ಇರಬಾರದಿತ್ತು. ಆದರೂ ಒಂದು authorisation ದೋಷವು ಆರ್ಕೈವ್ ಮಾಡಿದ ದಾಖಲೆಗಳಿಗೆ ಓದುವ ಪ್ರವೇಶವನ್ನು ನೀಡಿತು.

ಒಂದು ಆಫೀಸ್ ಕಟ್ಟಡವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಕಟ್ಟಡವು ಈ ಹಿಂದೆ ಲಾಕ್ ಮಾಡಿದ ಗೇಟ್ (VPN) ಹಿಂದೆ ಇತ್ತು. ನವೀಕರಣ ಕಾರ್ಯವು ಆ ಗೇಟ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿತು. ಫ್ರಂಟ್ ಡೆಸ್ಕ್ ಕೇಳಿದ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಸಂದರ್ಶಕರ ಬ್ಯಾಡ್ಜ್ (ಸೆಲ್ಫ್-ರಿಜಿಸ್ಟ್ರೇಷನ್) ನೀಡುತ್ತಿತ್ತು. ಬ್ಯಾಡ್ಜ್ ಯಾವುದೇ ಬಾಗಿಲನ್ನು ತೆರೆಯುವ ಉದ್ದೇಶವನ್ನು ಹೊಂದಿರಲಿಲ್ಲ, ಆದರೆ ಒಂದು ಸ್ಟೋರ್ ರೂಮ್ ಲಾಕ್ ಯಾವುದೇ ಬ್ಯಾಡ್ಜ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿತ್ತು (authorisation ದೋಷ).

ಪ್ರತಿಯೊಂದು ಭಾಗವು ಪ್ರತ್ಯೇಕವಾಗಿ ಬದುಕುಳಿಯಬಹುದಾದಂತೆ ಕಾಣಿಸಬಹುದು. ಆದರೆ ಒಟ್ಟಾಗಿ, ಅವು ಫೈಲ್‌ಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಿದವು.

Authentication ಎಂಬುದು authorisation ಅಲ್ಲ

ಇದು ಕೇಂದ್ರ ಪಾಠವಾಗಿದೆ, ಮತ್ತು ಇದು ಈ ಘಟನೆಯನ್ನು ಮೀರಿ ಅನ್ವಯಿಸುತ್ತದೆ.

ಲಾಗಿನ್ ಆಗಲು ಸಾಧ್ಯವಾಗುವುದು ತೀರಾ ಕಡಿಮೆ ವಿಷಯವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಖಾತೆಯೊಂದು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಯಾರೋ ಅದರ ರುಜುವಾತುಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ಅದು ಸಿಸ್ಟಮ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ. ಆದರೆ ಆ ಖಾತೆಯು ಆರ್ಕೈವ್‌ನಿಂದ ಪಾಸ್‌ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗಬೇಕೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಪ್ರಸಿದ್ಧ ಅಪ್ಲಿಕೇಶನ್ ಭದ್ರತಾ ಯೋಜನೆಯಾದ OWASP, ತನ್ನ authorisation ಮಾರ್ಗದರ್ಶನದಲ್ಲಿ ಈ ಎರಡು ಕಾರ್ಯಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. Authentication ಗುರುತನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. Authorisation ಆ ಗುರುತು ಯಾವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮತ್ತು ಕ್ರಿಯೆಗಳನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. OWASP ಮೂರು ಅಭ್ಯಾಸಗಳನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ:

• ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಪ್ರವೇಶವನ್ನು ನಿರಾಕರಿಸಿ.
• ಕನಿಷ್ಠ ಸವಲತ್ತುಗಳನ್ನು ಅನ್ವಯಿಸಿ, ಅಂದರೆ ಪ್ರತಿ ಖಾತೆಯು ತನಗೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವುದನ್ನು ಮಾತ್ರ ಪಡೆಯುತ್ತದೆ.
• ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯಲ್ಲೂ ಅನುಮತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಆರ್ಕೈವ್‌ಗೆ ಅನ್ವಯಿಸಿದಾಗ, ಆ ತತ್ವಗಳ ಪ್ರಕಾರ ಸ್ಪಷ್ಟವಾದ, ಸಮರ್ಥನೀಯ ಅನುಮತಿಯನ್ನು ನೀಡುವವರೆಗೆ ಹೊಚ್ಚ ಹೊಸ ಖಾತೆಯು ಯಾವುದೇ ಗ್ರಾಹಕರ ದಾಖಲೆಗಳನ್ನು ಸ್ವೀಕರಿಸಬಾರದು. ಯಾವುದೇ ಪಾತ್ರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆ ಇಲ್ಲದಿರುವುದು ನಿರಾಕರಣೆಯನ್ನು ಉಂಟುಮಾಡಬೇಕೇ ಹೊರತು, ಎಂದಿಗೂ ಫಾಲ್‌ಬ್ಯಾಕ್ ಅನುಮತಿಯನ್ನು ನೀಡಬಾರದು.

ನ್ಯಾಯಯುತವಾಗಿ ಮತ್ತು ನಿಖರವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಇದು OWASP ನ ಮಾರ್ಗದರ್ಶನದ ವಾಸ್ತುಶಿಲ್ಪದ ಅನ್ವಯವಾಗಿದೆ. ಇದು DigiCert ತನ್ನ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿದೆ ಎಂಬುದರ ಬಗೆಗಿನ ಹೆಚ್ಚುವರಿ ಆವಿಷ್ಕಾರವಲ್ಲ.

ಮೊದಲ ತನಿಖೆಯು ಇದನ್ನು ಏಕೆ ತಪ್ಪಿಸಿಕೊಂಡಿತು

DigiCert ಜೂನ್ 2026 ರಲ್ಲಿ ಖಾತೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿತು ಮತ್ತು ಮೊದಲಿಗೆ ಅವುಗಳು ಗ್ರಾಹಕರ ಮಾಹಿತಿಯನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ತೀರ್ಮಾನಿಸಿತು. ನಂತರದ ಪರಿಶೀಲನೆಯು ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ತೋರಿಸಿತು.

ಇದು ಸಂಭವಿಸುವುದು ತುಂಬಾ ಸುಲಭ, ಮತ್ತು ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯ. ನಿರ್ವಾಹಕರೊಬ್ಬರು ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸ್ಕ್ರೀನ್ ತೆರೆಯುತ್ತಾರೆ, ಯಾವುದೇ ಪಾತ್ರಗಳಿಲ್ಲದ ಖಾತೆಯನ್ನು ನೋಡುತ್ತಾರೆ, ಮತ್ತು ಅದು ಏನನ್ನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ತಾರ್ಕಿಕವಾಗಿ ತೀರ್ಮಾನಿಸುತ್ತಾರೆ. ಆದರೆ ಆ ಪರದೆಯು ಲೇಬಲ್‌ಗಳನ್ನು ಮಾತ್ರ ತೋರಿಸುತ್ತದೆ. ಖಾತೆಯು ಏನನ್ನಾದರೂ ವಿನಂತಿಸಿದಾಗ ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿಯೂ ಏನನ್ನು ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅದು ತೋರಿಸುವುದಿಲ್ಲ. ನಿಯೋಜಿಸದಂತೆ ತೋರುವ ಖಾತೆಯು ಕೇಂದ್ರ ಖಾತೆ-ನಿರ್ವಹಣಾ ಇಂಟರ್‌ಫೇಸ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸುವ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ತಲುಪುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ.

ಆದ್ದರಿಂದ ಅನಿರೀಕ್ಷಿತ ಖಾತೆಯೊಂದು ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಹುಟ್ಟುಹಾಕಬೇಕು:

1. ಅದರ ಪರಿಣಾಮಕಾರಿ ಅನುಮತಿಗಳು ಯಾವುವು, ಅಂದರೆ ಅದು ನಿಜವಾಗಿಯೂ ಏನು ಮಾಡಬಹುದು?
2. ಅದು ಯಾವ ಸೆಷನ್‌ಗಳನ್ನು ತೆರೆಯಿತು?
3. ಅದು ನಿಜವಾಗಿಯೂ ಯಾವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿನಂತಿಸಿತು?

ಇದೇ ಅನುಕ್ರಮದಲ್ಲಿ ಎರಡನೇ ಪಾಠವಿದೆ. ಪ್ರವೇಶದ ಮಾರ್ಗವನ್ನು ಮುಚ್ಚುವುದು ಮತ್ತು ನೀವು ಅದನ್ನು ಮುಚ್ಚುವ ಮೊದಲು ಏನಾಯಿತು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಎರಡು ಪ್ರತ್ಯೇಕ ಕೆಲಸಗಳು. DigiCert ಪರಿಹಾರಗಳನ್ನು ಪರಿಚಯಿಸಿತು, ಆದರೆ ಆ ಪರಿಹಾರಗಳು ದಾಖಲೆಗಳನ್ನು ಈಗಾಗಲೇ ಪ್ರವೇಶಿಸಲಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ತಕ್ಷಣವೇ ಸ್ಥಾಪಿಸಲಿಲ್ಲ. ಅಕ್ಟೋಬರ್ 19 ರಂದು ನಡೆದ ತಪಾಸಣೆಯು ಮಾತ್ರ ಜೂನ್ 27 ಮತ್ತು ಜುಲೈ 2 ರ ನಡುವೆ ಪ್ರವೇಶವನ್ನು ದೃಢಪಡಿಸಿತು.

ನೀವು ಅನುಮತಿಗಳ ವೈಫಲ್ಯವನ್ನು ಸರಿಪಡಿಸಿದಾಗಲೆಲ್ಲಾ, ಹಿಂದಿನದನ್ನು ಪರಿಶೀಲಿಸಲು ನೆನಪಿಡಿ. ಸರಿಪಡಿಸುವ ಮೊದಲು, ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಖಾತೆಗಳು ಅಥವಾ ಸೆಷನ್‌ಗಳು ಸೇರಿದಂತೆ, ಇದೇ ವೈಫಲ್ಯವನ್ನು ಬಳಸಲಾಗಿದೆಯೇ?

ಏನು ಬಹಿರಂಗವಾಯಿತು, ಮತ್ತು ಗುರುತಿನ ದಾಖಲೆಗಳು ಎಲ್ಲವನ್ನೂ ಏಕೆ ಬದಲಾಯಿಸುತ್ತವೆ

ಬಹಿರಂಗಗೊಂಡ ಮಾಹಿತಿಯು ಹೆಸರುಗಳು, ವ್ಯಾಪಾರ ಇಮೇಲ್ ವಿಳಾಸಗಳು, ದೂರವಾಣಿ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ವ್ಯಾಪಾರ ವಿಳಾಸಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಕೆಲವು ದಾಖಲೆಗಳು ಗುರುತಿನ ಪರಿಶೀಲನೆಗಾಗಿ ಸಲ್ಲಿಸಲಾದ ದಾಖಲೆಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿದ್ದವು.

ಯಾರು ಪ್ರಭಾವಿತರಾಗಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಗುರುತಿನ ದಾಖಲೆಗಳನ್ನು ಇನ್ನೂ ಪರಿಶೀಲಿಸುತ್ತಿರುವುದಾಗಿ ಮತ್ತು ಆ ಪರಿಶೀಲನೆ ಪೂರ್ಣಗೊಂಡ ನಂತರ ಆ ವ್ಯಕ್ತಿಗಳಿಗೆ ತಿಳಿಸುವುದಾಗಿ DigiCert ಹೇಳಿದೆ.

ಸಂಬಂಧಪಟ್ಟ ಜನರಿಗೆ, ವ್ಯತ್ಯಾಸವು ದೊಡ್ಡದಾಗಿದೆ. ಕೇವಲ ಕೆಲಸದ ಇಮೇಲ್ ದಾಖಲೆಯಲ್ಲಿದ್ದ ವ್ಯಕ್ತಿಗೆ ಒಂದು ರೀತಿಯ ಕಳವಳವಿರುತ್ತದೆ. ಪಾಸ್‌ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್ ಕೂಡ ಲಭ್ಯವಿದ್ದ ವ್ಯಕ್ತಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಕಳವಳವಿರುತ್ತದೆ. ಪಾಸ್‌ಪೋರ್ಟ್‌ನಲ್ಲಿ ಮುದ್ರಿಸಲಾದ ವಿವರಗಳಿಗಿಂತ ಇಮೇಲ್ ವಿಳಾಸವನ್ನು ನೀವು ಸುಲಭವಾಗಿ ಬದಲಾಯಿಸಬಹುದು.

ಪ್ರಮಾಣಪತ್ರ ಪೂರೈಕೆದಾರರೊಂದಿಗಿನ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಬಂಧವನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವ ಸಂದೇಶಗಳು ಸೇರಿದಂತೆ, ಉದ್ದೇಶಿತ ನಕಲಿ ಗುರುತಿನ ವಂಚನೆಗೆ (targeted impersonation) ಅವಕಾಶವಿರುವುದನ್ನು Brandefense ನ ಮೌಲ್ಯಮಾಪನವು ಸೂಚಿಸುತ್ತದೆ. ಯಾವ ಪ್ರತಿನಿಧಿಗಳು ಪರಿಶೀಲನಾ ದಾಖಲೆಗಳನ್ನು ಒದಗಿಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಅನುಮಾನಾಸ್ಪದ ಫಾಲೋ-ಅಪ್ ವಿನಂತಿಗಳ ಬಗ್ಗೆ ಅವರನ್ನು ಎಚ್ಚರಿಸಲು ಇದು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ.

ಇಲ್ಲಿ ಒಂದು ಸಂಭವನೀಯ ಉದಾಹರಣೆ ಇದೆ, ಮತ್ತು ಇದು ಕೇವಲ ಕಾಲ್ಪನಿಕವಾಗಿದೆ. ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಪ್ರಮಾಣಪತ್ರಗಳಿಗೆ ಅಡಚಣೆಯಾಗುವುದನ್ನು ತಪ್ಪಿಸಲು ನಿಮ್ಮ ಸಂಸ್ಥೆಯು ತನ್ನ ಗುರುತಿನ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಬೇಕು ಎಂದು ಸಂದೇಶವೊಂದು ಹೇಳುತ್ತದೆ. ಇದು ನಂಬಲರ್ಹವೆನಿಸಬಹುದು, ಏಕೆಂದರೆ ಇದು ನಿಖರವಾದ ಹೆಸರುಗಳು, ಸಂಪರ್ಕ ವಿವರಗಳು ಮತ್ತು ನಿಮ್ಮ ಪೂರೈಕೆದಾರರ ಬಗೆಗಿನ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿರಬಹುದು.

ಇವುಗಳು ಸಂಭವನೀಯ ಅಪಾಯಗಳು ಮತ್ತು ಜಾಣ್ಮೆಯ ಮುನ್ನೆಚ್ಚರಿಕೆಗಳಾಗಿವೆ. ಅಪರಾಧಿಗಳು ವಂಚನೆಗಾಗಿ ಈ ಡೇಟಾ ಉಲ್ಲಂಘನೆಯನ್ನು ಬಳಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಇವು ತೋರಿಸುವುದಿಲ್ಲ.

DigiCert ಯಾವುದರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ

ಈ ಭಾಗವು ಮುಖ್ಯವಾಗಿದೆ, ಮತ್ತು ಇದು ಕೆಟ್ಟ ಸುದ್ದಿಯಷ್ಟೇ ಕಾಳಜಿಗೆ ಅರ್ಹವಾಗಿದೆ.

ತನ್ನ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರ ಸೇವೆಗಳು, CertCentral ಮತ್ತು DigiCert ONE ಯಾವುದೇ ಪರಿಣಾಮಕ್ಕೆ ಒಳಗಾಗಿಲ್ಲ ಎಂದು DigiCert ಹೇಳಿದೆ. ಗ್ರಾಹಕರ ಲಾಗಿನ್ ರುಜುವಾತುಗಳು ಮತ್ತು ನೀಡಲಾದ ಪ್ರಮಾಣಪತ್ರಗಳು ಸುರಕ್ಷಿತವಾಗಿವೆ, ಮತ್ತು ಈ ಘಟನೆಯಿಂದಾಗಿ ಗ್ರಾಹಕರು ಸಕ್ರಿಯ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಅದು ಹೇಳಿದೆ.

ಅನಧಿಕೃತ ಖಾತೆಯು ದಾಖಲೆಗಳನ್ನು ಮಾರ್ಪಡಿಸಲು, ಮೌಲ್ಯೀಕರಣಗಳನ್ನು ಅನುಮೋದಿಸಲು ಅಥವಾ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನೀಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ತನ್ನ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಯಾವುದೇ ಸಂಬಂಧಿತ ಪ್ರಮಾಣಪತ್ರ ವಿತರಣೆ, ಮೌಲ್ಯೀಕರಣ ಅಥವಾ ರದ್ದತಿ ಚಟುವಟಿಕೆಗಳು ಕಂಡುಬಂದಿಲ್ಲ ಎಂದು ಕಂಪನಿ ತಿಳಿಸಿದೆ.

ಆದ್ದರಿಂದ ಗ್ರಾಹಕರಿಗೆ ತಕ್ಷಣದ ಪ್ರತಿಕ್ರಿಯೆಯು ಬಹಿರಂಗಗೊಂಡ ಮಾಹಿತಿ ಮತ್ತು ಅದರ ಹಿಂದಿರುವ ಜನರ ಬಗ್ಗೆಯಾಗಿದೆ. ಕಂಪನಿಯ ಹೇಳಿಕೆಯ ಪ್ರಕಾರ, ಈ ಘಟನೆಯಿಂದಾಗಿ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಅವಸರದಲ್ಲಿ ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ಇದರ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಒಂದು ಉಪಯುಕ್ತ ಮಾರ್ಗವಿದೆ. ಡೇಟಾ ಉಲ್ಲಂಘನೆಯ ಪರಿಣಾಮವು ಪ್ರತ್ಯೇಕ ಆಯಾಮಗಳನ್ನು ಹೊಂದಿದೆ:

• Confidentiality ಮಾಹಿತಿಯು ಬಹಿರಂಗವಾಗಿದೆಯೇ ಎಂದು ಕೇಳುತ್ತದೆ.
• Integrity ದಾಖಲೆಗಳು ಅಥವಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆಯೇ ಎಂದು ಕೇಳುತ್ತದೆ.

ರೈಟ್ ಆಕ್ಸೆಸ್ (write access) ಮೇಲಿನ ನಿರ್ಬಂಧವು ಸಮಗ್ರತೆಯನ್ನು ರಕ್ಷಿಸಬಹುದು, ಆದರೆ ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯನ್ನು ಇನ್ನೂ ಬಹಿರಂಗವಾಗಿಡಬಹುದು. ರೀಡ್-ಓನ್ಲಿ ಆಕ್ಸೆಸ್ ಹಾನಿಕಾರಕವಲ್ಲದಂತೆ ಕಾಣಿಸಬಹುದು, ಆದರೆ OWASP ಬ್ರೋಕನ್ ಆಕ್ಸೆಸ್ ಕಂಟ್ರೋಲ್‌ನ ಸಂಭವನೀಯ ಪರಿಣಾಮವಾಗಿ ಅನಧಿಕೃತ ಓದುವಿಕೆಯನ್ನು ಪಟ್ಟಿಮಾಡುತ್ತದೆ, ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳು ಎಷ್ಟು ಸೂಕ್ಷ್ಮವಾಗಿವೆ ಎಂಬುದರ ಮೇಲೆ ತೀವ್ರತೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ರೀಡ್ ಆಕ್ಸೆಸ್ ವೈಯಕ್ತಿಕ ದಾಖಲೆಗಳನ್ನು ತಲುಪಿದಾಗ, "read-only" ಎಂಬುದು ಯಾವುದೇ ಸಮಾಧಾನ ನೀಡುವುದಿಲ್ಲ.

DigiCert ಏನನ್ನು ಬದಲಾಯಿಸಿದೆ

ಇನ್ಸಿಡೆಂಟ್ ವರದಿಯು ಈ ಕೆಳಗಿನ ಸುಧಾರಣಾ ಕ್ರಮಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ:

• Self-registration ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ.
• Private endpoints.
• ವ್ಯವಹಾರ ವ್ಯವಸ್ಥೆಯ ಬಳಕೆದಾರರಿಗೆ ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆಗಳು.
• ಹೆಚ್ಚುವರಿ ಮಾನಿಟರಿಂಗ್.
• ಅನುಮತಿಗಳ ಪರಿಶೀಲನೆ.

ಬಾಹ್ಯ-ಎಕ್ಸ್‌ಪೋಸರ್ ಆಡಿಟ್ ಮತ್ತು ಅಂತಿಮ ಖಾತೆ-ಎಚ್ಚರಿಕೆ ಪರಿಶೀಲನೆಯನ್ನು ಪ್ರಸ್ತುತ ನಡೆಯುತ್ತಿದೆ ಎಂದು ಪಟ್ಟಿಮಾಡಲಾಗಿದೆ, ಇವುಗಳ ಗಡುವು 6 ನವೆಂಬರ್ 2026 ಆಗಿದೆ.

ಹೆಚ್ಚಿನ ವಾಸ್ತುಶಿಲ್ಪದ ಅಂಶವು NIST ನ Zero Trust Architecture ಮಾರ್ಗದರ್ಶನಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಕೇವಲ ನೆಟ್‌ವರ್ಕ್ ಸ್ಥಳ ಅಥವಾ ಮಾಲೀಕತ್ವದ ಕಾರಣದಿಂದಾಗಿ ಸಿಸ್ಟಮ್ ಅಥವಾ ಖಾತೆಯು ಯಾವುದೇ ಸೂಚ್ಯ ನಂಬಿಕೆಯನ್ನು ಪಡೆಯಬಾರದು ಎಂದು NIST ಹೇಳುತ್ತದೆ. ರಕ್ಷಣೆಯು ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಸ್ಪಷ್ಟ ಪ್ರವೇಶ ನಿರ್ಧಾರಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕೃತವಾಗಿರಬೇಕು.

ಇದು ಪ್ರತಿಯೊಂದು ಸಂಸ್ಥೆಗೂ ಒಂದು ಸರಳ ಮತ್ತು ಸ್ವಲ್ಪ ಅಹಿತಕರವಾದ ಪರೀಕ್ಷೆಯನ್ನು ನೀಡುತ್ತದೆ:

ಫೈರ್‌ವಾಲ್ ನಿಯಮ, ರೂಟಿಂಗ್ ಬದಲಾವಣೆ ಅಥವಾ ಮೈಗ್ರೇಷನ್ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಅದನ್ನು ಪ್ರವೇಶಿಸುವಂತೆ ಮಾಡಿದರೆ, ಈ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ಅನಧಿಕೃತ ವಿನಂತಿಯನ್ನು ನಿರಾಕರಿಸುತ್ತದೆಯೇ?

ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಬಂಧಗಳು ಇನ್ನೂ ಉಪಯುಕ್ತವಾಗಿವೆ. ಆದರೆ ಅವು ಬಾಗಿಲನ್ನು ಮುಚ್ಚಿ ಹಿಡಿದಿರುವ ಏಕೈಕ ವಿಷಯವಾಗಿರಬಾರದು ಅಷ್ಟೇ.

ನಮಗೆ ಇನ್ನೂ ತಿಳಿಯದಿರುವ ವಿಷಯಗಳು

ಪ್ರಾಮಾಣಿಕ ವರದಿ ಎಂದರೆ ಕೊರತೆಗಳನ್ನೂ ಪಟ್ಟಿ ಮಾಡುವುದು ಎಂದರ್ಥ.

• ಸಾರ್ವಜನಿಕ ಪ್ರಕಟಣೆಯು ಬಾಧಿತ ಜನರು, ಸಂಸ್ಥೆಗಳು ಅಥವಾ ಗುರುತಿನ ದಾಖಲೆಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯನ್ನು ನೀಡುವುದಿಲ್ಲ.
• Cybersixt ನ ಸ್ವತಂತ್ರ ವರದಿಯು ಖಾತೆಯ ಆಪರೇಟರ್ ಅನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ಗುರುತಿಸಲಾಗಿಲ್ಲ ಎಂದು ಗಮನಿಸಿದೆ.
• ಆ ಸಂಖ್ಯೆಗಳಿಲ್ಲದೆ, "ಆರ್ಕೈವ್ ಮಾಡಿದ ಡೇಟಾದ ಒಂದು ಸಣ್ಣ ಭಾಗ" ದಂತಹ ವಿವರಣೆಯು ಎಷ್ಟು ಜನರಿಗೆ ಬೆಂಬಲ ಬೇಕು, ಅಥವಾ ಪ್ರತಿಯೊಬ್ಬ ವ್ಯಕ್ತಿಯ ಮಾಹಿತಿ ಎಷ್ಟು ಸೂಕ್ಷ್ಮವಾಗಿ ಬಹಿರಂಗವಾಗಿದೆ ಎಂಬುದನ್ನು ನಮಗೆ ತಿಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಪ್ರಮಾಣವನ್ನು ತಿಳಿಸುವ ಯಾವುದೇ ಮುಖ್ಯಾಂಶದ ಬಗ್ಗೆ ಜಾಗರೂಕರಾಗಿರಿ. ಸದ್ಯಕ್ಕೆ, ಆ ಸಂಖ್ಯೆ ಸಾರ್ವಜನಿಕವಾಗಿಲ್ಲ.

ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆ 1: ರೋಹಿತ್ ಗ್ರಾಹಕರ ಬಳಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾನೆ

ಈಗ ನಾವು ಒಂದು ಕಾಲ್ಪನಿಕ ಕಂಪನಿಯನ್ನು ನೋಡೋಣ. Acme ಎಂಬುದು ಪೂರೈಕೆದಾರರಿಂದ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಖರೀದಿಸುವ ಮಧ್ಯಮ ಗಾತ್ರದ ಸಂಸ್ಥೆಯಾಗಿದೆ. ಅದರ ಸೆಕ್ಯುರಿಟಿ ಲೀಡ್ ರೋಹಿತ್, ಶುಕ್ರವಾರ ಬೆಳಿಗ್ಗೆ ಈ ಸುದ್ದಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾನೆ. ಪ್ರತಿ ಹೆಸರು ಮತ್ತು ವಿಳಾಸ ಸೇರಿದಂತೆ ಕೆಳಗಿನ ಪ್ರತಿಯೊಂದೂ ಕೇವಲ ವಿವರಣಾತ್ಮಕ ಉದಾಹರಣೆಯಾಗಿದೆ.

ಹಂತ 1: ಪ್ರಮಾಣಪತ್ರಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಬೇಡಿ

ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ರೋಹಿತ್‌ನ ಮೊದಲ ಪ್ರವೃತ್ತಿಯಾಗಿದೆ, ಆದರೆ ಸಕ್ರಿಯ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಪೂರೈಕೆದಾರರ ಹೇಳಿಕೆ ತಿಳಿಸುತ್ತದೆ. ಅವುಗಳನ್ನು ಆತುರದಲ್ಲಿ ಬದಲಾಯಿಸುವುದು ನಿಜವಾದ ಕಾಳಜಿಯನ್ನು ಪರಿಹರಿಸದೆ ಅಪಾಯ ಮತ್ತು ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ರೋಹಿತ್ ಇಂದಿನ ದಿನದ ನಿಜವಾದ ಪ್ರಶ್ನೆಯನ್ನು ಬರೆದುಕೊಳ್ಳುತ್ತಾನೆ: ನಮ್ಮವರಲ್ಲಿ ಯಾರ ಮಾಹಿತಿ ಬಹಿರಂಗಗೊಂಡಿದೆ?

ಹಂತ 2: ಜನರ ಪಟ್ಟಿಯನ್ನು ಸಿದ್ಧಪಡಿಸಿ

Acme ಗಾಗಿ ಈ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಹಿಂದೆ ಯಾರಾದರೂ ವ್ಯವಹರಿಸಿದ್ದಾರೆಯೇ ಎಂದು Rohit ಪ್ರಮಾಣಪತ್ರ ನಿರ್ವಹಣಾ ತಂಡವನ್ನು ಕೇಳುತ್ತಾನೆ. ಹಿಂದಿನ ಉದ್ಯೋಗಿಗಳೂ ಇದರಲ್ಲಿ ಸೇರುತ್ತಾರೆ, ಏಕೆಂದರೆ ಬಹಳ ಹಿಂದೆಯೇ ಸಂಸ್ಥೆಯನ್ನು ತೊರೆದ ವ್ಯಕ್ತಿಗಳ ವಿವರಗಳೂ ಆರ್ಕೈವ್‌ಗಳಲ್ಲಿ ಇರುತ್ತವೆ.

ಪಟ್ಟಿಯು ಸರಳವಾಗಿದ್ದು, ಪ್ರತಿ ವ್ಯಕ್ತಿಗೆ ಮೂರು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ:

Name         Role              Gave contact details   Gave identity document
A. Sample    Network engineer  yes                    unknown
B. Sample    Finance manager   yes                    yes (from old emails)
C. Sample    Former employee   yes                    unknown

"unknown" ಎಂಬ ಪದವು ಪ್ರಾಮಾಣಿಕ ಮತ್ತು ಉಪಯುಕ್ತವಾಗಿದೆ. ಇದು ಮುಂದಿನ ಪ್ರಶ್ನೆಗಳ ಸಮೂಹವಾಗುತ್ತದೆ.

ಹಂತ 3: ಸರಬರಾಜುದಾರರಿಗೆ ನಿಖರವಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ

ಅಸ್ಪಷ್ಟ ಇಮೇಲ್‌ಗೆ ಅಸ್ಪಷ್ಟ ಉತ್ತರವೇ ಬರುತ್ತದೆ. Rohit ಸ್ಥಾಪಿತ ಖಾತೆ ಸಂಪರ್ಕದ ಮೂಲಕ ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ:

1. ನಮ್ಮ ಯಾವ ಜನರು ಮತ್ತು ಯಾವ ದಾಖಲೆಗಳು ಇದರಲ್ಲಿ ಒಳಗೊಂಡಿದ್ದವು?
2. ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಯಾವ ಸಾಕ್ಷ್ಯಾಧಾರವು ದೃಢಪಡಿಸುತ್ತದೆ?
3. ನೀವು ಮುಂದಿನ ವೈಯಕ್ತಿಕ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸುವ ನಿರೀಕ್ಷೆಯಿದೆಯೇ?

ನಂತರ Rohit ಪ್ರತಿಯೊಂದು ಉತ್ತರವನ್ನು ದಿನಾಂಕದೊಂದಿಗೆ ದಾಖಲಿಸುತ್ತಾನೆ, ಇದರಿಂದ ಯಾವಾಗ ಏನು ತಿಳಿದುಬಂದಿತ್ತು ಎಂದು ತಂಡವು ನಂತರ ತಿಳಿಯಬಹುದು.

ಹಂತ 4: Privacy ಮತ್ತು HR ತಂಡಗಳನ್ನು ಒಳಗೊಳ್ಳಿ

ಪ್ರಮಾಣಪತ್ರಗಳ ಬಗೆಗಿನ ತಾಂತ್ರಿಕ ಭರವಸೆಯು ಸಿಬ್ಬಂದಿಯ ಅಗತ್ಯಗಳನ್ನು ಮರೆಮಾಚಬಾರದು. Rohit ಪ್ರಮಾಣಪತ್ರ ತಂಡ, ಭದ್ರತೆ ಮತ್ತು ಗೌಪ್ಯತೆ (privacy) ಸಹೋದ್ಯೋಗಿಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತಾನೆ. ಪಟ್ಟಿಯಲ್ಲಿರುವ ಜನರಿಗೆ, ಪ್ರಶ್ನೆಯು ವೈಯಕ್ತಿಕವಾಗಿದೆ: "ನನ್ನ ಪಾಸ್‌ಪೋರ್ಟ್ ಅದರಲ್ಲಿತ್ತೇ?" ಉತ್ತರ ದೊರೆತ ತಕ್ಷಣ ಅವರಿಗೆ ನೇರವಾದ ಉತ್ತರ ಸಿಗಬೇಕು, ಮತ್ತು ಅಲ್ಲಿಯವರೆಗೆ ಸ್ಪಷ್ಟವಾದ "ನಮಗೆ ಇನ್ನೂ ತಿಳಿದಿಲ್ಲ" ಎಂಬ ಮಾಹಿತಿಯನ್ನು ನೀಡಬೇಕು.

ಹಂತ 5: ದಾಳಿಕೋರರು ಜನರನ್ನು ತಲುಪುವ ಮುನ್ನವೇ ಅವರನ್ನು ಎಚ್ಚರಿಸಿ

Rohit ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಒಂದು ಸಣ್ಣ ಟಿಪ್ಪಣಿಯನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ:

You may be contacted about our certificate provider.
Do not upload identity documents, click links or confirm details
because of a message, even one that uses accurate names.
Report it to [email protected]. We will verify it through a
known contact.

ಸಂಪೂರ್ಣ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಇದು ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ ಮಾನವೀಯ ಹಂತವಾಗಿದೆ. ಬದಲಿ ಗುರುತಿನ ದಾಖಲೆಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವ ಯಾವುದೇ ಸೂಚನೆಯನ್ನು ಪರಿಚಿತ ಸಂಪರ್ಕ ಅಥವಾ ಅಧಿಕೃತ ಸೇವೆಯ ಮೂಲಕ ಸ್ವತಂತ್ರವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕು.

ಹಂತ 6: ವಾಡಿಕೆಯ ಭದ್ರತಾ ಕ್ರಮಗಳನ್ನು ಕೈಗೊಳ್ಳಿ, ಮತ್ತು ಅದನ್ನು ಸರಿಯಾಗಿ ಹೆಸರಿಸಿ

Rohit ಪೂರೈಕೆದಾರರ ಪೋರ್ಟಲ್‌ನಲ್ಲಿ ಖಾತೆಯ ಬಳಕೆದಾರರು ಮತ್ತು API ಕೀಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾನೆ, ಮಾಜಿ ಉದ್ಯೋಗಿಯೊಬ್ಬರ ಪ್ರವೇಶಾವಕಾಶವನ್ನು ತೆಗೆದುಹಾಕುತ್ತಾನೆ. ಇದು ವಾಡಿಕೆಯ ಭದ್ರತಾ ನೈರ್ಮಲ್ಯವಾಗಿದೆ (routine security hygiene). ರಾಜಿ ಮಾಡಿಕೊಂಡ ರುಜುವಾತುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಇದನ್ನು ವಿವರಿಸಬಾರದು, ಏಕೆಂದರೆ ಅವು ಸುರಕ್ಷಿತವಾಗಿಯೇ ಉಳಿದಿವೆ ಎಂದು ಪೂರೈಕೆದಾರರು ಹೇಳುತ್ತಾರೆ. ನಿಖರವಾದ ಪದಬಳಕೆಯು ಕಂಪನಿಯೊಳಗಿನ ವದಂತಿಗಳನ್ನು ತಡೆಯುತ್ತದೆ.

ಹಂತ 7: ಪ್ರಕರಣವನ್ನು ಮುಕ್ತವಾಗಿರಿಸಿ

ಪೂರೈಕೆದಾರರು ಇನ್ನೂ ಗುರುತಿನ ದಾಖಲೆಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ಪ್ರಕರಣವು ಮುಕ್ತವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ. Rohit ಪ್ರತಿ ವಾರ ಪರಿಶೀಲನೆಯನ್ನು ನಿಗದಿಪಡಿಸುತ್ತಾನೆ ಮತ್ತು ಸರಬರಾಜುದಾರರ ಅಧಿಸೂಚನೆಗಳು ಪೂರ್ಣಗೊಂಡು ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಬ್ಬ ವ್ಯಕ್ತಿಗೂ ಉತ್ತರ ಸಿಕ್ಕ ನಂತರವೇ ಅದನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತಾನೆ.

ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆ 2: Rohit Acme ನ ಸ್ವಂತ ಆರ್ಕೈವ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾನೆ

ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾದ ಪ್ರಶ್ನೆ ಮುಂದೆ ಬರುತ್ತದೆ. ಇದು ನಮಗೂ ಸಂಭವಿಸಬಹುದೇ? Rohit ಹಳೆಯ ಆಂತರಿಕ ಸಾಧನವನ್ನು (internal tool) ಆಯ್ಕೆಮಾಡುತ್ತಾನೆ, archive.example.com, ಇದು ಸ್ಕ್ಯಾನ್ ಮಾಡಲಾದ ಸರಬರಾಜುದಾರರ ಒಪ್ಪಂದಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸಿಬ್ಬಂದಿ ಇದನ್ನು VPN ಮೂಲಕ ಪ್ರವೇಶಿಸುತ್ತಾರೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಇದು ಸುರಕ್ಷಿತವೆಂದು ಭಾವಿಸುತ್ತಾರೆ. ಇಂತಹ ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಅಥವಾ ಪರೀಕ್ಷಿಸಲು ಅನುಮತಿ ಇರುವ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ನಡೆಸಿ.

ಹಂತ 1: ನೀವು ಏನನ್ನು ಇರಿಸಿಕೊಂಡಿದ್ದೀರಿ, ಮತ್ತು ಏಕೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡಿ

ಯಾವುದನ್ನಾದರೂ ಪರೀಕ್ಷಿಸುವ ಮೊದಲು, Rohit ದಾಖಲೆಗಳ ಕುರಿತಾದ ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತಾನೆ:

• ಅವುಗಳನ್ನು ಏಕೆ ಸಂಗ್ರಹಿಸಲಾಯಿತು?
• ಅವುಗಳ ಪ್ರತಿಗಳು ಎಲ್ಲಿ ಉಳಿದಿವೆ?
• ಅವುಗಳನ್ನು ಯಾರು ಹಿಂಪಡೆಯಬಹುದು?
• ಪ್ರವೇಶವನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ?

ಮೊದಲನೆಯ ಪ್ರಶ್ನೆಯು ಹೆಚ್ಚಾಗಿ ತ್ವರಿತ ಪರಿಹಾರವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸ್ಕ್ಯಾನ್ ಮಾಡಿದ ದಾಖಲೆಯನ್ನು ಇನ್ನೂ ಏಕೆ ಇರಿಸಲಾಗಿದೆ ಎಂದು ಯಾರೂ ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅದನ್ನು ಗೌಪ್ಯತೆ ತಂಡದೊಂದಿಗೆ ಪ್ರಸ್ತಾಪಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.

ಹಂತ 2: ಖಾತೆಯನ್ನು ರಚಿಸಲು ಇರುವ ಪ್ರತಿಯೊಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳಿ

Rohit ಸೈನ್-ಅಪ್ ಪುಟಗಳು, ಆಹ್ವಾನ ಲಿಂಕ್‌ಗಳು ಮತ್ತು ಸಿಂಗಲ್ ಸೈನ್-ಆನ್ (single sign-on) ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತಾನೆ. ಹಳೆಯ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ ಸ್ವಯಂ-ನೋಂದಣಿ (self-registration) ವೈಶಿಷ್ಟ್ಯವು ವರ್ಷಗಳ ಕಾಲ ಗಮನಕ್ಕೆ ಬಾರದೆ ಉಳಿದುಕೊಂಡಿರಬಹುದು. ಸಿಬ್ಬಂದಿಯಿಂದ ರಚಿಸಲ್ಪಡದ ಖಾತೆಗಳು ಸೇರಿದಂತೆ ಪ್ರತಿಯೊಂದು ಖಾತೆಗೂ ಅದೇ MFA ನಿಯಮವು ಅನ್ವಯಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಸಹ Rohit ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತಾನೆ.

ಹಂತ 3: ನೆಟ್‌ವರ್ಕ್ ತಡೆಗೋಡೆ ಇಲ್ಲ ಎಂದು ಭಾವಿಸಿಕೊಳ್ಳಿ

ಅನುಮೋದಿತ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ, VPN ಮಾರ್ಗವನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಪರೀಕ್ಷಾ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ, Rohit ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೇರವಾಗಿ ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ. ನಂತರ, ಯಾವುದೇ ಪಾತ್ರವನ್ನು ಹೊಂದಿರದ ಹೊಸ ಖಾತೆಯೊಂದಿಗೆ, Rohit ದಾಖಲೆಯೊಂದನ್ನು ವಿನಂತಿಸುತ್ತಾನೆ:

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer REPLACE_WITH_TEST_TOKEN" \
  https://archive.example.com/api/documents/1001

Rohit ಬಯಸುವ ಉತ್ತರವೆಂದರೆ 401 ಅಥವಾ 403, ಅಂದರೆ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ. ಒಂದು 200 ಎಂದರೆ ಖಾತೆಯು ದಾಖಲೆಯನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂದರ್ಥ, ಮತ್ತು admin ಸ್ಕ್ರೀನ್‌ನಲ್ಲಿ ಖಾತೆಯು "ಯಾವುದೇ ಅನುಮತಿಗಳನ್ನು ಹೊಂದಿಲ್ಲ" ಎಂದಿದ್ದರೂ ಸಹ ಅದೊಂದು ಭದ್ರತಾ ಸಂಶೋಧನೆಯಾಗಿದೆ (finding).

ಹಂತ 4: ಕೇವಲ ಮುಖ್ಯ ಬಾಗಿಲನ್ನಷ್ಟೇ ಅಲ್ಲ, ಪ್ರತಿಯೊಂದು ಬಾಗಿಲನ್ನೂ ಪರೀಕ್ಷಿಸಿ

ಪುಟಗಳ ನಡುವೆ ಅನುಮತಿ ಪರಿಶೀಲನೆಗಳು ಭಿನ್ನವಾಗಿರಬಹುದು, ಆದ್ದರಿಂದ Rohit ಹುಡುಕಾಟ, ರಫ್ತು, ಡೌನ್‌ಲೋಡ್ ಮತ್ತು API ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾನೆ. ವೆಬ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಬಟನ್ ಅನ್ನು ಮರೆಮಾಡಬಹುದು ಆದರೆ ಅದರ ಹಿಂದಿರುವ ಸರ್ವರ್ ಇನ್ನೂ ಸ್ಪಂದಿಸುತ್ತಿರಬಹುದು. ಪರೀಕ್ಷೆಯು ಯಾವಾಗಲೂ ಸರ್ವರ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಬೇಕು.

ಹಂತ 5: ತಿರಸ್ಕಾರವನ್ನು ಡೀಫಾಲ್ಟ್ ನಿಯಮವಾಗಿಸಿ

ತರ್ಕವು ಈ ರೂಪವನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸಲು Rohit ಡೆವಲಪರ್‌ಗಳನ್ನು ಕೇಳುತ್ತಾನೆ. ಇದು deny-by-default ನ ಸರಳ ವಿವರಣೆಯಾಗಿದೆ, ಯಾವುದೇ ನೈಜ ಉತ್ಪನ್ನದ ಕೋಡ್ ಅಲ್ಲ:

def can_read(user, document):
    if user is None:
        return False
    # No explicit grant means no access. There is no fallback.
    return document.id in user.explicit_grants

ಇಲ್ಲಿ ಮುಖ್ಯವಾದ ಅಂಶವೆಂದರೆ ಯಾವುದು ಇಲ್ಲ ಎಂಬುದು. ಇಲ್ಲಿ ಯಾವುದೇ "otherwise allow" ಶಾಖೆಯಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ನಿಯೋಜನೆಗಳಿಲ್ಲದ ಖಾತೆಗೆ ಯಾವುದೇ ದಾಖಲೆಗಳು ಸಿಗುವುದಿಲ್ಲ.

ಹಂತ 6: ಮುಖ್ಯವಾದ ಸಂಕೇತದ ಮೇಲೆ ನಿಗಾ ಇರಿಸಿ

Rohit ಹೊಸ ಬಾಹ್ಯ ಖಾತೆಗಳಿಗಾಗಿ ಮತ್ತು ರಚನೆಯಾದ ಕೆಲವೇ ಸಮಯದಲ್ಲಿ ಹಲವು ದಾಖಲೆಗಳನ್ನು ಓದುವ ಯಾವುದೇ ಖಾತೆಗಾಗಿ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸೇರಿಸುತ್ತಾನೆ. ಹೊಸ ಖಾತೆಯ ಮೇಲಿನ ಎಚ್ಚರಿಕೆಯು ಉಪಯುಕ್ತವಾಗುವುದು ಯಾರಾದರೂ ಆ ಖಾತೆಯು ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿದಾಗ ಮಾತ್ರ.

ಹಂತ 7: ಪರಿಶೀಲನಾ ಪಟ್ಟಿಗೆ ಮೈಗ್ರೇಷನ್‌ಗಳನ್ನು ಸೇರಿಸಿ

ಅಂತಿಮವಾಗಿ, Rohit ಮೈಗ್ರೇಷನ್ ಪರಿಶೀಲನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತಾನೆ. ಈ ಹಿಂದೆ ಅದು, "ಸ್ಥಳಾಂತರದ ನಂತರ ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ?" ಎಂದು ಕೇಳುತ್ತಿತ್ತು. ಈಗ ಅದು, "ಹಿಂದೆ ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗದಿರುವುದು ಈಗ ಏನನ್ನು ಪ್ರವೇಶಿಸಬಹುದು, ಮತ್ತು ಆ ಸೇವೆಗಳು ಹೇಗೆ ವರ್ತಿಸುತ್ತವೆ?" ಎಂದು ಸಹ ಕೇಳುತ್ತದೆ. ಯಾರು ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬ ಊಹೆಗಳು ಅವು ಆಧಾರಿತವಾಗಿದ್ದ ಮೂಲಸೌಕರ್ಯಕ್ಕಿಂತಲೂ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯಬಹುದು, ಮತ್ತು ಹಳೆಯ ವ್ಯಾಪಾರ ಸಾಧನಗಳಲ್ಲಿ ಇದು ಹೆಚ್ಚಾಗಿ ಸಂಭವಿಸುತ್ತದೆ.

ಭದ್ರತಾ ನಾಯಕರಿಗೆ ವ್ಯಾಪಕವಾದ ಪಾಠ

ಆರ್ಕೈವ್‌ಗಳು ನೀರಸವಾಗಿ ಕಾಣಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವು ಲೈವ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆ ಗಮನವನ್ನು ಪಡೆಯುತ್ತವೆ. ಆದರೆ ಅವುಗಳ ಒಳಗಿರುವ ಡೇಟಾ ಸಾಮಾನ್ಯವಾಗಿ ಹಳೆಯದಾಗಿರುತ್ತದೆ, ಕಡಿಮೆ ಪರಿಶೀಲಿಸಲ್ಪಟ್ಟಿರುತ್ತದೆ ಮತ್ತು ಅಷ್ಟೇ ಸೂಕ್ಷ್ಮವಾಗಿರುತ್ತದೆ. ಆರ್ಕೈವ್‌ನ ಕಾರ್ಯಾಚರಣೆಯ ಗೋಚರತೆ ಕಡಿಮೆಯಾಗಿದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಅದರಲ್ಲಿರುವ ಮಾಹಿತಿಗೆ ಒದಗಿಸಲಾದ ರಕ್ಷಣೆಯು ಕಡಿಮೆಯಾಗಬಾರದು.

ಪರಿಶೀಲನಾ ದಾಖಲೆಯ ಸಂಗ್ರಹಣೆಯಿಂದ ಹಿಡಿದು ಅಳಿಸುವಿಕೆಯವರೆಗಿನ ಸಂಪೂರ್ಣ ಜೀವನಚಕ್ರವನ್ನು ಗಮನಿಸಿ. ಅದನ್ನು ಏಕೆ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಪ್ರತಿಗಳು ಎಲ್ಲಿ ಉಳಿಯುತ್ತವೆ, ಅದನ್ನು ಯಾರು ಹಿಂಪಡೆಯಬಹುದು ಮತ್ತು ಪ್ರವೇಶವನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. ಮೈಗ್ರೇಷನ್ ನಿಮ್ಮ ಮೇಲೆ ಆ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇರುವ ಮುನ್ನವೇ ಅವುಗಳನ್ನು ಕೇಳಿಕೊಳ್ಳಿ.

ಉಪಸಂಹಾರ

DigiCert ಘಟನೆಯು ಪ್ರಮಾಣಪತ್ರಗಳು ನಕಲಿಯಾಗಿರುವುದರ ಕುರಿತಾದ ಕಥೆಯಲ್ಲ. ಕಂಪನಿಯ ವಿವರಣೆಯ ಪ್ರಕಾರ, ಪ್ರಮಾಣಪತ್ರ ಕಾರ್ಯಾಚರಣೆಗಳು ಸುರಕ್ಷಿತವಾಗಿಯೇ ಉಳಿದಿವೆ. ಇದು ಪ್ರವೇಶಿಸಬಹುದಾದಂತಾದ ಒಂದು ವ್ಯವಸ್ಥೆ, ಏನನ್ನೂ ನೋಡಬಾರದಾಗಿದ್ದ ಖಾತೆಗಳು ಮತ್ತು ಸೂಕ್ಷ್ಮ ದಾಖಲೆಗಳನ್ನು ತಲುಪಿದ ರೀಡ್ ಆಕ್ಸೆಸ್‌ನ (read access) ಬಗೆಗಿನ ಕಥೆಯಾಗಿದೆ. ನೀವು ಗ್ರಾಹಕರಾಗಿದ್ದರೆ, ಯಾವ ಜನರು ಬಾಧಿತರಾಗಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಕಂಡುಕೊಳ್ಳಿ, ಅವರನ್ನು ಎಚ್ಚರಿಸಿ ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ವಿನಂತಿಗಳನ್ನು ಪರಿಚಿತ ಮಾರ್ಗದ ಮೂಲಕ ಪರಿಶೀಲಿಸಿ. ನೀವು ಬೇರೆ ಯಾರೇ ಆಗಿದ್ದರೂ, ನೆಟ್‌ವರ್ಕ್ ತಡೆಗೋಡೆ ಈಗಾಗಲೇ ಇಲ್ಲ ಎಂಬ ಊಹೆಯ ಮೇಲೆ ನಿಮ್ಮ ಆರ್ಕೈವ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಯಾವುದೋ ಒಂದು ದಿನ ಮೈಗ್ರೇಷನ್ ಅದನ್ನು ನಿಜವಾಗಿಸಬಹುದು.

ಪ್ರಯೋಜನಗಳು

• ಗ್ರಾಹಕರಿಗೆ ಸಕ್ರಿಯ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಸ್ಪಷ್ಟ, ಪ್ರಾಯೋಗಿಕ ಹಂತಗಳಿವೆ.
• ಸಾರ್ವಜನಿಕ ಘಟನಾ ವರದಿಯು ಪ್ರತಿಯೊಂದು ತಂಡಕ್ಕೂ ಕಲಿಯಲು ಒಂದು ನೈಜ ಪ್ರಕರಣವನ್ನು ಒದಗಿಸುತ್ತದೆ.
• ಇಲ್ಲಿ ವಿವರಿಸಲಾದ ಪರೀಕ್ಷೆಯು ಕಡಿಮೆ ವೆಚ್ಚದ್ದಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ಹಳೆಯ ಆಂತರಿಕ ಸಾಧನಕ್ಕೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
• ಸಂಗ್ರಹಿಸಲಾದ ದಾಖಲೆಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದರಿಂದ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಡೇಟಾವನ್ನು ತೆಗೆದುಹಾಕಿ ಭವಿಷ್ಯದ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
• Authorisation ಅನ್ನು ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣವಾಗಿ ಪರಿಗಣಿಸುವುದು ನೆಟ್‌ವರ್ಕ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಬದಲಾದಾಗಲೂ ವ್ಯವಸ್ಥೆಗಳನ್ನು ರಕ್ಷಿಸುತ್ತದೆ.

ಅನಾನುಕೂಲಗಳು

• ದಾಖಲೆಗಳ ಪರಿಶೀಲನೆ ಮುಂದುವರಿದಿರುವಾಗ ಬಾಧಿತ ಜನರು ಉತ್ತರಗಳಿಗಾಗಿ ಕಾಯಬೇಕಾಗಬಹುದು.
• ಸಾರ್ವಜನಿಕ ಅಂಕಿಅಂಶಗಳು ಲಭ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ನೈಜ ಪ್ರಮಾಣವನ್ನು ಇನ್ನೂ ನಿರ್ಣಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
• ಹಳೆಯ ಆರ್ಕೈವ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸಮಯ ಹಿಡಿಯುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ ಸಾಧನಗಳ ದಾಖಲೀಕರಣ ಸರಿಯಾಗಿಲ್ಲದಿರಬಹುದು.
• ಪ್ರತಿಯೊಂದು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಾದ್ಯಂತ ಅನುಮತಿ ಪರೀಕ್ಷೆಗೆ ಕೌಶಲ್ಯ ಮತ್ತು ಅನುಮೋದಿತ ಪರೀಕ್ಷಾ ಪರಿಸರಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ.
• ವಾಸ್ತವಾಂಶಗಳು ಇನ್ನೂ ಅಪೂರ್ಣವಾಗಿರುವಾಗ ಸಿಬ್ಬಂದಿಗೆ ನೀಡುವ ಎಚ್ಚರಿಕೆಗಳು ಆತಂಕಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕ ಉದ್ದೇಶದ್ದಾಗಿದೆ ಮತ್ತು ಬರೆಯುವ ಸಮಯದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಸಾರ್ವಜನಿಕ ವರದಿಗಳನ್ನು ಆಧರಿಸಿದೆ, ಆದ್ದರಿಂದ ತನಿಖೆ ಮುಂದುವರಿದಂತೆ ವಿವರಗಳು ಬದಲಾಗಬಹುದು. Acme, Rohit, ಮಾದರಿ ಸಿಬ್ಬಂದಿ, ವಿಳಾಸಗಳು, ಟೋಕನ್ ಮತ್ತು ಕೋಡ್ ಕಾಲ್ಪನಿಕ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳಾಗಿದ್ದು, ಅವುಗಳನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕು. ನಿಮ್ಮ ಸ್ವಂತ ಅಥವಾ ಪರೀಕ್ಷಿಸಲು ನಿಮಗೆ ಅಧಿಕಾರವಿರುವ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗುವ ಮೊದಲು DigiCert ನ ಸ್ವಂತ ಸೂಚನೆಗಳು ಹಾಗೂ ನಿಮ್ಮ ಕಾನೂನು ಅಥವಾ ಗೌಪ್ಯತೆ ಸಲಹೆಗಾರರೊಂದಿಗೆ ಹೇಳಿಕೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• DigiCert ಉಲ್ಲಂಘನೆಯಲ್ಲಿ ಏನು ಸಂಭವಿಸಿತು? — 4 February 2025 ರಂದು ನಡೆದ ಮೈಗ್ರೇಷನ್ VPN-ನಿರ್ಬಂಧಿತ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಾಹ್ಯವಾಗಿ ಪ್ರವೇಶಿಸುವಂತೆ ಮಾಡಿತು, ಹೊರಗಿನವರು ಖಾತೆಗಳನ್ನು ಸ್ವಯಂ-ನೋಂದಾಯಿಸಲು ಸಾಧ್ಯವಾಯಿತು, ಮತ್ತು authorisation ದೌರ್ಬಲ್ಯವು ಆ ಖಾತೆಗಳಿಗೆ ಆರ್ಕೈವ್ ಮಾಡಲಾದ ದಾಖಲೆಗಳಿಗೆ read access ನೀಡಿತು.
• ಯಾವ ಡೇಟಾ ಬಹಿರಂಗವಾಯಿತು? — ಹೆಸರುಗಳು, ವ್ಯಾಪಾರ ಇಮೇಲ್ ವಿಳಾಸಗಳು, ದೂರವಾಣಿ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ವ್ಯಾಪಾರ ವಿಳಾಸಗಳು, ಹಾಗೂ ಪಾಸ್‌ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ಚಾಲನಾ ಪರವಾನಗಿಗಳಂತಹ ಕೆಲವು ದಾಖಲೆಗಳಲ್ಲಿನ ಗುರುತಿನ ದಾಖಲೆಗಳು.
• ನನ್ನ DigiCert ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನಾನು ಬದಲಾಯಿಸಬೇಕೇ? — ಈ ಘಟನೆಯ ಕಾರಣದಿಂದಾಗಿ ಗ್ರಾಹಕರು ಸಕ್ರಿಯ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ನೀಡಲಾದ ಪ್ರಮಾಣಪತ್ರಗಳು ಹಾಗೂ ಲಾಗಿನ್ ರುಜುವಾತುಗಳು ಸುರಕ್ಷಿತವಾಗಿವೆ ಎಂದು DigiCert ಹೇಳುತ್ತದೆ.
• CertCentral ಮತ್ತು DigiCert ONE ಬಾಧಿತವಾಗಿದ್ದವೇ? — ತನ್ನ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರ ಸೇವೆಗಳು, CertCentral ಮತ್ತು DigiCert ONE ಬಾಧಿತವಾಗಿಲ್ಲ ಮತ್ತು ಅದರ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಯಾವುದೇ ಸಂಬಂಧಿತ issuance, validation ಅಥವಾ revocation ಚಟುವಟಿಕೆಗಳು ಕಂಡುಬಂದಿಲ್ಲ ಎಂದು DigiCert ಹೇಳುತ್ತದೆ.
• ಎಷ್ಟು ಜನರು ಬಾಧಿತರಾಗಿದ್ದಾರೆ? — ಸಾರ್ವಜನಿಕ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯು ಜನರು, ಸಂಸ್ಥೆಗಳು ಅಥವಾ ಗುರುತಿನ ದಾಖಲೆಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯನ್ನು ನೀಡಿಲ್ಲ, ಮತ್ತು ತಾನು ಇನ್ನೂ ಗುರುತಿನ ದಾಖಲೆಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿರುವುದಾಗಿ DigiCert ಹೇಳುತ್ತದೆ.
• ಬಾಧಿತ ಗ್ರಾಹಕರು ಈಗ ಏನು ಮಾಡಬೇಕು? — ಯಾರು ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಿ, ಗುರುತಿನ ದಾಖಲೆಗಳನ್ನು ಸಲ್ಲಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಸಂದೇಶಗಳನ್ನು ಸ್ಥಾಪಿತ ಮಾರ್ಗಗಳ ಮೂಲಕ ಪರಿಶೀಲಿಸಿ.
• Authentication ಮತ್ತು authorisation ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು? — Authentication ನೀವು ಯಾರೆಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಆದರೆ authorisation ನೀವು ಏನನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೇವಲ ಯಶಸ್ವಿ ಲಾಗಿನ್ ಮಾತ್ರವೇ ಎಂದಿಗೂ ಸೂಕ್ಷ್ಮ ದಾಖಲೆಗಳನ್ನು ಅನ್‌ಲಾಕ್ ಮಾಡಬಾರದು.
• ಈ ಸಮಸ್ಯೆಗಾಗಿ ನನ್ನ ಸ್ವಂತ ಆರ್ಕೈವ್ ಅನ್ನು ನಾನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಬಹುದು? — ಅಧಿಕೃತ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ಯಾವುದೇ role ಇಲ್ಲದ ಖಾತೆಯನ್ನು ರಚಿಸಿ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಿಂದ ನೇರವಾಗಿ ದಾಖಲೆಗಳನ್ನು ವಿನಂತಿಸಿ; ತಿರಸ್ಕಾರವನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆ ಬಂದರೂ ಅದು ಒಂದು finding ಆಗಿದೆ.

ಟ್ಯಾಗ್‌ಗಳು

#DigiCert #DataBreach #IdentityDocuments #AccessControl #Authorisation #IncidentResponse #ZeroTrust #OWASP #PrivacyRisk #CyberSecurity