ಪಾಸ್‌ವರ್ಡ್ ತ್ಯಜಿಸಬಹುದಾದಾಗ ಅದನ್ನು ಏಕೆ ರಕ್ಷಿಸಬೇಕು?

ನಾವು ಸಹಜವೆಂದು ಭಾವಿಸಲು ಕಲಿತ ಸಮಸ್ಯೆ

ಬಹುತೇಕ ಪ್ರತಿಯೊಂದು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೂ ಆಡಳಿತಾತ್ಮಕ ಫಲಕವಿರುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಆ ಫಲಕಕ್ಕೆ ಪ್ರವೇಶ ವಿಳಾಸ, ದೃಢೀಕರಣ ಫಾರ್ಮ್, ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಇರುತ್ತವೆ.

ಈ ವ್ಯವಸ್ಥೆಗೆ ನಾವು ಎಷ್ಟರಮಟ್ಟಿಗೆ ಒಗ್ಗಿಕೊಂಡಿದ್ದೇವೆಂದರೆ, ಎಲ್ಲವೂ ಹೀಗೆಯೇ ಕೆಲಸ ಮಾಡಬೇಕೇ ಎಂದು ಕೇಳುವುದನ್ನೇ ಬಹುತೇಕ ನಿಲ್ಲಿಸಿದ್ದೇವೆ.

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

ಆದರೆ ಯೋಜನೆಗಳ ಸಂಖ್ಯೆ ಹತ್ತು, ಇಪ್ಪತ್ತು ಅಥವಾ ಮೂವತ್ತಾದಾಗ ಏನಾಗುತ್ತದೆ?

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

ಹೀಗಾಗಿ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ವ್ಯವಸ್ಥೆಯ ಅಗತ್ಯವಿದೆ.

ದೀರ್ಘಕಾಲ ನಾನು ಸಾಕಷ್ಟು ಪರಿಚಿತವಾದ ವಿಧಾನವನ್ನೇ ಬಳಸುತ್ತಿದ್ದೆ: ಪ್ರತ್ಯೇಕ ಆಡಳಿತಾತ್ಮಕ ಖಾತೆ ವಿವರಗಳು, ಬಲವಾದ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಉಳಿಸಿಡುವುದು.

ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು.

ಆದರೆ ಒಂದು ಹಂತದಲ್ಲಿ ನಾನು ಯೋಚಿಸಿದೆ: ಇಷ್ಟೊಂದು ಆಡಳಿತಾತ್ಮಕ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನಾನು ಏಕೆ ಸಂಗ್ರಹಿಸಬೇಕು? ಸರ್ವರ್‌ಗಳನ್ನು ಮಾತ್ರವಲ್ಲ, ಅವುಗಳಿಗೆ ಪ್ರವೇಶ ಪಡೆಯುವ ಸಾಧನಗಳನ್ನೂ ಏಕೆ ರಕ್ಷಿಸಬೇಕು?

ಈ ಅಗತ್ಯವನ್ನೇ ತ್ಯಜಿಸಲು ಸಾಧ್ಯವಿಲ್ಲವೇ?

ನಂತರ ನನ್ನ ಪರಿಹಾರದ ಆಧಾರವಾದ ಒಂದು ಆಲೋಚನೆಗೆ ಬಂದೆ:

ಶಾಶ್ವತ ಪ್ರವೇಶವನ್ನು ರಕ್ಷಿಸುವ ಬದಲು, ತಾತ್ಕಾಲಿಕವಾಗಿ ಪ್ರವೇಶ ಪಡೆಯುವ ಹಕ್ಕನ್ನೇ ರಕ್ಷಿಸುವುದು ಉತ್ತಮವಿರಬಹುದು.

ಪರಿಚಿತ ಪ್ರವೇಶ ಪುಟವೇ ಇಲ್ಲದಿದ್ದರೆ ಹೇಗೆ?

ನನ್ನ ಯೋಜನೆಗಳಲ್ಲಿ ಸಾಂಪ್ರದಾಯಿಕ ಆಡಳಿತಾತ್ಮಕ ದೃಢೀಕರಣ ಮಾದರಿಯನ್ನು ತ್ಯಜಿಸಲು ನಿರ್ಧರಿಸಿದೆ.

ಲಾಗಿನ್ ಫಾರ್ಮ್ ಅನ್ನು ಕೇವಲ ಮರೆಮಾಡುವುದಲ್ಲ.

ವಿಳಾಸದ ಹೆಸರನ್ನು ಬದಲಿಸುವುದಲ್ಲ.

ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಇನ್ನೂ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಪಾಸ್‌ವರ್ಡ್‌ನಿಂದ ಬದಲಿಸುವುದಲ್ಲ.

ಬದಲಾಗಿ, ಯಾವಾಗಲೂ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪಾಸ್‌ವರ್ಡ್ ಆಧಾರಿತ ಪ್ರವೇಶದ ಅಗತ್ಯವನ್ನೇ ತೆಗೆದುಹಾಕುವುದು.

ಖಂಡಿತವಾಗಿಯೂ, ಆಡಳಿತಾತ್ಮಕ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಕಣ್ಮರೆಯಾಗಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಅವು ಇನ್ನೂ ಅಗತ್ಯವಿವೆ.

ಅವುಗಳಿಗೆ ಪ್ರವೇಶ ಪಡೆಯುವ ವಿಧಾನ ಮಾತ್ರ ಬದಲಾಗಿದೆ.

ಈಗ, ಸಂಪರ್ಕಿತ ಯೋಜನೆಗಳ ಆಡಳಿತಾತ್ಮಕ ಫಲಕಗಳಿಗೆ ಪ್ರವೇಶಿಸಲು ಉಳಿಸಿಟ್ಟ ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ನಮೂದಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ಅದರ ಬದಲಿಗೆ, ನಾನು MeldID ಎಂಬ ನನ್ನದೇ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಪ್ರವೇಶ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುತ್ತೇನೆ.

ಇದರ ತತ್ವ ತುಂಬಾ ಸರಳ: ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶವನ್ನು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವಾಗ ಮಾತ್ರ, ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರಿಗೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಯೋಜನೆಗೆ ನೀಡಲಾಗುತ್ತದೆ.

ಖಾತೆ ಹೊಂದಿರುವುದರಿಂದಲೇ ಆಡಳಿತಾತ್ಮಕ ಫಲಕ ತೆರೆಯುವ ಹಕ್ಕು ಸಿಗುವುದಿಲ್ಲ.

ಆ ಹಕ್ಕನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೀಡಬೇಕು.

ಒಂದು ನಿಮಿಷದ ಹಿಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲೇ ಇಲ್ಲದ ಪ್ರವೇಶ

ಇದು ಬಹುಶಃ ಈ ಪರಿಕಲ್ಪನೆಯ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಭಾಗ.

ಸಾಂಪ್ರದಾಯಿಕ ಮಾದರಿಯಲ್ಲಿ, ನಿರ್ವಾಹಕರ ಬಳಿ ಪ್ರವೇಶದ ಸಾಧನಗಳು ಯಾವಾಗಲೂ ಇರುತ್ತವೆ. ಅವು ಮಾನ್ಯವಾಗಿರುವವರೆಗೆ, ಅವರು ಇಂದು, ನಾಳೆ ಅಥವಾ ಒಂದು ತಿಂಗಳ ನಂತರವೂ ಅವುಗಳನ್ನು ಬಳಸಬಹುದು.

ನಾನು ಈ ತತ್ವವನ್ನು ಬದಲಿಸಲು ನಿರ್ಧರಿಸಿದೆ.

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

ವಿಶ್ವಾಸಾರ್ಹ ಮೊಬೈಲ್ ಸಾಧನದ ಮೂಲಕ ವಿನಂತಿಸಿದಾಗ ಅದು ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ. ಅದರಲ್ಲಿ ಕ್ರಿಪ್ಟೋಗ್ರಫಿಯಿಂದ ಸುರಕ್ಷಿತವಾದ ಯಾದೃಚ್ಛಿಕ ಅಂಶವಿದ್ದು, ಅದರ ಮಾನ್ಯತಾ ಅವಧಿಯೂ ಸೀಮಿತವಾಗಿರುತ್ತದೆ.

ಆದರೆ ಇಂತಹ ತಾತ್ಕಾಲಿಕ ಲಿಂಕ್ ಹೊಂದಿರುವುದರಿಂದಲೇ ಪ್ರವೇಶ ಸಿಗುವುದಿಲ್ಲ.

ಇದು ಮೂಲಭೂತವಾಗಿ ಮುಖ್ಯವಾದ ಅಂಶ.

ಯಾರಾದರೂ ಹೇಗಾದರೂ ಆ ಲಿಂಕ್ ಪಡೆದಿದ್ದಾರೆಂದು ಊಹಿಸೋಣ. ವಿಳಾಸದ ರಹಸ್ಯತೆಯನ್ನೇ ಅವಲಂಬಿಸಿರುವ ಸಾಮಾನ್ಯ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಇಂತಹ ಸೋರಿಕೆ ಗಂಭೀರ ಸಮಸ್ಯೆಯಾಗಬಹುದು.

ನನ್ನ ಮಾದರಿಯಲ್ಲಿ, ಲಿಂಕ್ ದೃಢೀಕರಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆರಂಭಿಸಲು ಮಾತ್ರ ಅವಕಾಶ ನೀಡುತ್ತದೆ.

ಮುಂದುವರಿಯಲು MeldIDಯ ವಿಶ್ವಾಸಾರ್ಹ ಮೊಬೈಲ್ ಸಾಧನದ ಮೂಲಕ ಪ್ರತ್ಯೇಕ ಅನುಮತಿ ಅಗತ್ಯ.

ಅಗತ್ಯ ದೃಢೀಕರಣವಿಲ್ಲದೆ ಆಡಳಿತಾತ್ಮಕ ಸೆಷನ್ ಸೃಷ್ಟಿಯಾಗುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದಲೇ ನಾನು ತಾತ್ಕಾಲಿಕ ಲಿಂಕ್ ಅನ್ನು ಪಾಸ್‌ವರ್ಡ್‌ಗೆ ಪರ್ಯಾಯವಾಗಿ ಅಲ್ಲ, ಪ್ರವೇಶ ನೀಡುವ ಪ್ರಕ್ರಿಯೆಯ ಒಂದು ಅಂಶವಾಗಿ ಪರಿಗಣಿಸುತ್ತೇನೆ.

ಎಲ್ಲಿಗೆ ಸಂಪರ್ಕಿಸಬೇಕು ಎಂದು ತಿಳಿದಿರುವುದು ಮತ್ತು ಪ್ರವೇಶಿಸುವ ಹಕ್ಕು ಹೊಂದಿರುವುದು — ಇವೆರಡೂ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ವಿಷಯಗಳು.

ಪ್ರವೇಶ ನಿರ್ವಹಣೆಯ ಸಾಧನವಾಗುವ ಫೋನ್

ಈ ಮಾದರಿಯಲ್ಲಿ, ಮೊಬೈಲ್ ಸಾಧನವು ಸಾಮಾನ್ಯ ಒಮ್ಮೆ ಬಳಕೆಯ ಕೋಡ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುವ ಸಾಧನಕ್ಕಿಂತಲೂ ಹೆಚ್ಚು ಮಹತ್ವದ ಪಾತ್ರ ವಹಿಸುತ್ತದೆ.

ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಕ್ರಮಗಳನ್ನು ದೃಢೀಕರಿಸಲು ಅದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ನಾನು ಆಡಳಿತಾತ್ಮಕ ಫಲಕ ತೆರೆಯಲು ಬಯಸಿದಾಗ, MeldID ಮೂಲಕ ದೃಢೀಕರಣವನ್ನು ಸಿಸ್ಟಮ್ ಕೇಳುತ್ತದೆ.

ವಿಶ್ವಾಸಾರ್ಹ ಸಾಧನದಲ್ಲಿ ಸಂಬಂಧಿತ ವಿನಂತಿಯನ್ನು ನೋಡಿ, ಆ ಕ್ರಮವನ್ನು ನಾನು ದೃಢೀಕರಿಸುತ್ತೇನೆ.

ಪರಿಶೀಲನೆ ಯಶಸ್ವಿಯಾದ ನಂತರವೇ ಪ್ರವೇಶ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮುಂದುವರಿಸಲು ಸಿಸ್ಟಮ್ ಅನುಮತಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ದೃಢೀಕರಣವು ಫೋನ್ ಅನ್‌ಲಾಕ್ ಆಗಿರುವುದಕ್ಕೆ ಮಾತ್ರವಲ್ಲ, ನಿರ್ದಿಷ್ಟ ಕ್ರಮಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ.

ಮೊಬೈಲ್ ಬಯೋಮೆಟ್ರಿಕ್ಸ್ ಸಾಧನದಲ್ಲೇ ಬಳಕೆದಾರರನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ; ಸರ್ವರ್ ಬದಿಯು ನೋಂದಾಯಿತ ಸಾಧನದಿಂದ ಬಂದ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ದೃಢೀಕರಣವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

ಈ ವಿಧಾನದಿಂದ ಪಾಸ್‌ವರ್ಡ್ ಒಂದನ್ನೇ ಅಥವಾ ಬಳಕೆದಾರರು ಪ್ರವೇಶವನ್ನು ದೃಢೀಕರಿಸಿದ್ದಾರೆ ಎಂಬ ಸಂದೇಶವನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿಸುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.

ಇದರಿಂದ ಮತ್ತೊಂದು ಪ್ರಯೋಜನವೂ ದೊರೆಯುತ್ತದೆ: ವಿಶ್ವಾಸಾರ್ಹ ಸಾಧನಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದು.

ಒಂದು ಸಾಧನವನ್ನು ಪ್ರವೇಶ ದೃಢೀಕರಣಕ್ಕೆ ಇನ್ನು ಬಳಸಬಾರದೆಂದಾದರೆ, ಅದರ ವಿಶ್ವಾಸಾರ್ಹ ಸ್ಥಿತಿಯನ್ನು ಹಿಂಪಡೆಯಬಹುದು.

ಆ ಬಳಿಕ, ಸಂಬಂಧಿತ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಅದು ಮಾನ್ಯ ದೃಢೀಕರಣ ಸಾಧನವಾಗಿ ಉಳಿಯುವುದಿಲ್ಲ.

ಒಂದು ವ್ಯವಸ್ಥೆ — ಅನೇಕ ಸ್ವತಂತ್ರ ಯೋಜನೆಗಳು

ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಆರಂಭಿಸಿದಾಗ, ಪ್ರತಿಯೊಂದು ಯೋಜನೆಯ ಸ್ವತಂತ್ರತೆಯನ್ನು ಉಳಿಸುವುದು ನನ್ನ ಪ್ರಮುಖ ಗುರಿಗಳಲ್ಲೊಂದಾಗಿತ್ತು.

ಎಲ್ಲ ಆಡಳಿತಾತ್ಮಕ ಫಲಕಗಳನ್ನು ಒಂದೇ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಒಗ್ಗೂಡಿಸಲು ನನಗೆ ಇಷ್ಟವಿರಲಿಲ್ಲ.

ಪ್ರತಿಯೊಂದು DigiMeld ಸೇವೆಯೂ ತನ್ನದೇ ಆದ ಲಾಜಿಕ್, ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಬಳಕೆದಾರರು ಮತ್ತು ಡೇಟಾವನ್ನು ನಿರ್ವಹಿಸುತ್ತಲೇ ಇರಬೇಕು.

ಆದ್ದರಿಂದ ನಾನು ಈ ಎರಡು ಕೆಲಸಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿದೆ.

ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ಅನುಮತಿ ನೀಡುವ ಜವಾಬ್ದಾರಿ MeldIDಯದು.

ಆದರೆ ಯೋಜನೆಯು ತನ್ನದೇ ಆಡಳಿತಾತ್ಮಕ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಅಧಿಕಾರಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

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

ಅಲ್ಲದೆ, ಹಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೀಡಲಾಗುತ್ತದೆ.

ಒಂದು ಯೋಜನೆಯ ನಿರ್ವಾಹಕರಿಗೆ MeldID ಖಾತೆ ಇದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಉಳಿದ ಯೋಜನೆಗಳಿಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರವೇಶ ಸಿಗುವುದಿಲ್ಲ.

ಪ್ರತಿಯೊಂದು ಆಡಳಿತಾತ್ಮಕ ವಿಭಾಗಕ್ಕೂ ಅನುಮತಿಸಲಾದ ಬಳಕೆದಾರರ ಪ್ರತ್ಯೇಕ ಗುಂಪನ್ನು ನಿಗದಿಪಡಿಸಬಹುದು.

ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರ ಹಕ್ಕುಗಳು ಮತ್ತು ಆಡಳಿತಾತ್ಮಕ ಅಧಿಕಾರಗಳು ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತವೆ.

ಹತ್ತಾರು ಸೇವೆಗಳ ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಅನುಕೂಲಕರವಾಗಿತ್ತು.

ಶಾಶ್ವತ ಪ್ರವೇಶಕ್ಕಿಂತ ತಾತ್ಕಾಲಿಕ ಪ್ರವೇಶ ನನಗೇಕೆ ಹೆಚ್ಚು ಇಷ್ಟ

ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಾನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಳವಡಿಸಿದ ಮತ್ತೊಂದು ತತ್ವವಿದೆ.

ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ಅನಿರ್ದಿಷ್ಟ ಕಾಲ ಉಳಿಯಬಾರದು.

ಅನುಮತಿ ಸೀಮಿತ ಅವಧಿಗೆ ಮಾತ್ರ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮುಂದುವರಿಸುತ್ತಿದ್ದಾರೆಯೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ.

ಅವಧಿ ಮುಗಿದ ನಂತರ ಕೆಲಸ ಮುಂದುವರಿಸಲು ಹೊಸ ದೃಢೀಕರಣ ಪ್ರಕ್ರಿಯೆ ಅಗತ್ಯ.

ಹೀಗೆ, ಒಮ್ಮೆ ಮಾಡಿದ ದೃಢೀಕರಣವು ನಿರಂತರವಾಗಿ ಮಾನ್ಯವಾಗಿರುವ ಹಕ್ಕಾಗಿ ಬದಲಾಗುವುದನ್ನು ತಡೆಯಬಹುದು.

ಆದರೆ ಸಮಯದ ಮಿತಿ ಮಾತ್ರ ಸಾಕಾಗುವುದಿಲ್ಲ.

ಈಗಾಗಲೇ ನೀಡಿರುವ ಪ್ರವೇಶವನ್ನು ಅವಧಿ ಮುಗಿಯುವ ಮೊದಲೇ ಕೊನೆಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವೂ ಮುಖ್ಯ.

ಆದ್ದರಿಂದ MeldIDಯಲ್ಲಿ ಆಡಳಿತಾತ್ಮಕ ಅನುಮತಿಗಳನ್ನು ಕೇಂದ್ರೀಕೃತವಾಗಿ ಹಿಂಪಡೆಯುವ ವ್ಯವಸ್ಥೆಯಿದೆ.

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

ಹೀಗಾಗಿ, ಬಳಕೆದಾರರು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರವೇಶಿಸಿದ ಕ್ಷಣಕ್ಕೆ ಪ್ರವೇಶ ನಿರ್ವಹಣೆ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ.

ಅಧಿಕಾರ ನೀಡುವ ಸಾಮರ್ಥ್ಯದಷ್ಟೇ ಅದನ್ನು ಹಿಂಪಡೆಯುವ ಸಾಮರ್ಥ್ಯವೂ ನನಗೆ ಮುಖ್ಯ.

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

ದೈನಂದಿನ ಕೆಲಸದಲ್ಲಿ ಏನು ಬದಲಾಯಿತು?

ಮೊದಲನೆಯದಾಗಿ, ಉಳಿಸಿಟ್ಟ ಆಡಳಿತಾತ್ಮಕ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನಿರಂತರವಾಗಿ ಬಳಸಬೇಕಾದ ಅಗತ್ಯ ಇಲ್ಲವಾಯಿತು.

ಸಂಪರ್ಕಿತ ಪ್ರತಿಯೊಂದು ಆಡಳಿತಾತ್ಮಕ ಫಲಕಕ್ಕೂ ಪ್ರವೇಶಿಸಲು ಬೇಕಾದ ಖಾತೆ ವಿವರಗಳನ್ನು ಇನ್ನು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ.

ಅದರ ಬದಲಿಗೆ, ಒಂದೇ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಅನುಮತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೇನೆ.

ಬೇಕಾದ ಯೋಜನೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ, ಪ್ರವೇಶವನ್ನು ದೃಢೀಕರಿಸಿ, ಕೆಲಸ ಮಾಡುತ್ತೇನೆ.

ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ಇನ್ನು ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ, ಅದನ್ನು ಹಿಂಪಡೆಯಬಹುದು.

ಹೊಸ ಯೋಜನೆ ಸೇರಿಸಿದಾಗ, ಆಡಳಿತಾತ್ಮಕ ದೃಢೀಕರಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಮತ್ತೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂಬುದು ವಿಶೇಷವಾಗಿ ಅನುಕೂಲಕರವಾಗಿದೆ.

ಅದನ್ನು ಈಗಿರುವ ಮಾದರಿಗೆ ಸಂಪರ್ಕಿಸಿ, ಅಗತ್ಯ ಅನುಮತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿದರೆ ಸಾಕು.

ಖಂಡಿತವಾಗಿಯೂ, ಇದರಿಂದ ಎಲ್ಲ ಭದ್ರತಾ ಅಪಾಯಗಳೂ ಕಣ್ಮರೆಯಾಗುತ್ತವೆ ಎಂದರ್ಥವಲ್ಲ.

ತಾತ್ಕಾಲಿಕ ಅನುಮತಿಗಳು, ವಿಶ್ವಾಸಾರ್ಹ ಸಾಧನಗಳು, ಸರ್ವರ್ ಸೆಷನ್‌ಗಳು ಮತ್ತು ಕೇಂದ್ರ ಮೂಲಸೌಕರ್ಯಗಳಿಗೂ ರಕ್ಷಣೆ ಅಗತ್ಯ.

ಆದರೆ ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲೂ ಆಡಳಿತಾತ್ಮಕ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಒಂದೇ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಹರಿಸುವ ಅಗತ್ಯ ನನಗಿಲ್ಲ.

ಮತ್ತು ಇದು ನನ್ನ ಆರಂಭಿಕ ಗುರಿಗಳಲ್ಲೊಂದಾಗಿತ್ತು.

ಇಂತಹ ತಂತ್ರಜ್ಞಾನಗಳು ಈಗಾಗಲೇ ಇಲ್ಲವೇ?

ಖಂಡಿತವಾಗಿಯೂ ಇವೆ.

ಪಾಸ್‌ವರ್ಡ್‌ರಹಿತ ದೃಢೀಕರಣ, ವಿಶೇಷಾಧಿಕಾರ ಪ್ರವೇಶ ನಿರ್ವಹಣೆ, ತಾತ್ಕಾಲಿಕ ಅನುಮತಿಗಳು ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಸಾಧನಗಳ ಮೂಲಕ ದೃಢೀಕರಣ — ಇವೆಲ್ಲವೂ ಮಾಹಿತಿ ಭದ್ರತಾ ಕ್ಷೇತ್ರದಲ್ಲಿ ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಪರಿಚಿತವಾಗಿವೆ.

ಇಂತಹ ವಿಧಾನಗಳು Identity and Access Management, Privileged Access Management ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಮತ್ತು Zero Trust ಪರಿಕಲ್ಪನೆಗಳಲ್ಲಿ ಕಾಣಸಿಗುತ್ತವೆ.

ಈ ತತ್ವಗಳನ್ನು ಆವಿಷ್ಕರಿಸಿದ್ದೇನೆಂದು ನಾನು ಹೇಳಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ನನ್ನ ಉದ್ದೇಶ ಬೇರೆ ಆಗಿತ್ತು.

DigiMeld ಮೂಲಸೌಕರ್ಯದ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಮತ್ತು ಅನೇಕ ಸ್ವತಂತ್ರ ಯೋಜನೆಗಳ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶವನ್ನು ನಿರ್ವಹಿಸಲು ನೆರವಾಗುವ, ನನ್ನದೇ ಆದ ಸಂಯೋಜಿತ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವ ಅಗತ್ಯವಿತ್ತು.

ಅದರ ಫಲವಾಗಿ, ನನ್ನ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಹಲವು ಪರಿಚಿತ ವಿಧಾನಗಳನ್ನು ಒಗ್ಗೂಡಿಸಿದೆ.

ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸದ ಮೌಲ್ಯವು ಸಂಪೂರ್ಣ ಹೊಸ ತಂತ್ರಜ್ಞಾನವನ್ನು ಆವಿಷ್ಕರಿಸುವುದರಲ್ಲೇ ಇರಬೇಕೆಂದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಕೆಲವೊಮ್ಮೆ, ಸಮಸ್ಯೆಯನ್ನು ಸರಿಯಾಗಿ ರೂಪಿಸಿ ಅದಕ್ಕೆ ಸೂಕ್ತ ಪರಿಹಾರ ಕಂಡುಕೊಳ್ಳುವುದೇ ಅದರ ಮೌಲ್ಯವಾಗಿರುತ್ತದೆ.

MeldID ಕೇವಲ ಆಡಳಿತಾತ್ಮಕ ಫಲಕಗಳಿಗಾಗಿ ಮಾತ್ರವಲ್ಲ

ಇಲ್ಲಿ ಒಂದು ವಿಷಯವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸ್ಪಷ್ಟಪಡಿಸಬೇಕು.

MeldIDಯನ್ನು ನನ್ನದೇ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶಕ್ಕಾಗಿ ಮಾತ್ರ ರಚಿಸಲಿಲ್ಲ.

ಅದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ತಮ್ಮದೇ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಪ್ರವೇಶ ದೃಢೀಕರಣದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಸಂಯೋಜಿಸಲು SDK ಕೂಡ ಒದಗಿಸುತ್ತದೆ.

ಈ SDK ಉಚಿತವಾಗಿ ಲಭ್ಯವಿದೆ.

ಉದಾಹರಣೆಗೆ, ಹೊರಗಿನ ಡೆವಲಪರ್ ಬಳಕೆದಾರರ ದೃಢೀಕರಣಕ್ಕೆ ಹೆಚ್ಚುವರಿ ಹಂತವಾಗಿ MeldIDಯನ್ನು ಬಳಸಬಹುದು.

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

ಬಳಕೆದಾರರ ವಿಶ್ವಾಸಾರ್ಹ ಮೊಬೈಲ್ ಸಾಧನಕ್ಕೆ ವಿನಂತಿ ಬರುತ್ತದೆ; ಅಲ್ಲಿ ಅವರು ಪ್ರವೇಶ ಪ್ರಯತ್ನವನ್ನು ದೃಢೀಕರಿಸಬಹುದು ಅಥವಾ ತಿರಸ್ಕರಿಸಬಹುದು.

ಖಾತೆ ವಿವರಗಳು ಸೋರಿಕೆಯಾದಾಗ ಅನಧಿಕೃತ ಪ್ರವೇಶದ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

MeldIDಯ ಎಲ್ಲರಿಗೂ ಲಭ್ಯವಿರುವ ಈ ಸಾಮರ್ಥ್ಯ ಮತ್ತು DigiMeld ಯೋಜನೆಗಳಿಗಾಗಿ ನಾನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ಮಾದರಿ — ಇವೆರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸುವುದು ಮುಖ್ಯ.

ಇವೆರಡೂ ನಂಬಿಕೆ ಮತ್ತು ಕ್ರಮಗಳ ದೃಢೀಕರಣದ ಸಾಮಾನ್ಯ ತತ್ವಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಆದರೆ ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ.

ಭದ್ರತೆ ಎಂದರೆ ಇರುವುದನ್ನು ರಕ್ಷಿಸುವುದಷ್ಟೇ ಅಲ್ಲ

ಈ ವ್ಯವಸ್ಥೆಯ ಮೇಲಿನ ಕೆಲಸವು, ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ದೃಢೀಕರಣ ವಿಧಾನಗಳನ್ನು ಬೇರೆ ದೃಷ್ಟಿಯಿಂದ ನೋಡುವಂತೆ ಮಾಡಿತು.

ಐತಿಹಾಸಿಕ ಕಾರಣಗಳಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವ್ಯವಸ್ಥೆಗಳನ್ನೇ ರಕ್ಷಿಸಲು ನಾವು ಆಗಾಗ ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.

ಹೊಸ ಪರಿಶೀಲನೆಗಳು, ನಿರ್ಬಂಧಗಳು, ಹೆಚ್ಚುವರಿ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಮತ್ತು ರಕ್ಷಣಾ ಪದರಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ.

ಕೆಲವೊಮ್ಮೆ ಇದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.

ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಬೇರೆ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವುದು ಹೆಚ್ಚು ಉಪಯುಕ್ತ:

ನಾವು ರಕ್ಷಿಸುತ್ತಿರುವ ವ್ಯವಸ್ಥೆಯು ಇದೇ ಹಳೆಯ ರೂಪದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರಲೇಬೇಕೇ?

ನನ್ನ ವಿಷಯದಲ್ಲಿ, ಉತ್ತರ ಇಲ್ಲ ಎಂದಾಗಿತ್ತು.

ನನಗೆ ನಿರಂತರವಾಗಿ ಲಭ್ಯವಿರುವ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ಫಾರ್ಮ್ ಅಗತ್ಯವಿರಲಿಲ್ಲ.

ಆಡಳಿತಾತ್ಮಕ ಅಧಿಕಾರ ಅಗತ್ಯವಿರುವಾಗಲೇ ಅದನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯ ಬೇಕಿತ್ತು.

ಇವೆರಡೂ ಬೇರೆ ಬೇರೆ ಗುರಿಗಳು.

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

ಅಂತಿಮ ನಿಲುಗಡೆಯಲ್ಲ, ಆಯ್ದ ದಿಕ್ಕು

ಇಂದು, ಈ ವಾಸ್ತುಶಿಲ್ಪವು DigiMeld ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಬಹುಪಾಲಿನಲ್ಲಿ ಈಗಾಗಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.

ಉಳಿದ ಯೋಜನೆಗಳನ್ನು ಕ್ರಮೇಣ ಹೊಸ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ಮಾದರಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತಿದೆ.

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

ಇಂಟರ್‌ಫೇಸ್‌ನ ಕೆಲವು ಅಂಶಗಳು ಮತ್ತು ಸೆಷನ್ ನಿರ್ವಹಣೆಯ ನಿಯಮಗಳು ಇನ್ನೂ ಬದಲಾಗಬಹುದು.

ಆದರೆ ಮುಖ್ಯ ಆಲೋಚನೆ ಈಗಾಗಲೇ ಸ್ಪಷ್ಟವಾಗಿದೆ.

ನನ್ನದೇ ಹತ್ತಾರು ಯೋಜನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಹತ್ತಾರು ಆಡಳಿತಾತ್ಮಕ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನಿರಂತರವಾಗಿ ಸಂಗ್ರಹಿಸಿ ಬಳಸಬೇಕಾದ ಮಾದರಿಗೆ ನಾನು ಮರಳಲು ಬಯಸುವುದಿಲ್ಲ.

ಆದರೆ ನನ್ನ ಅನುಷ್ಠಾನವೇ ಎಲ್ಲರಿಗೂ ಸೂಕ್ತವಾದ ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರ ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ.

ವಿಭಿನ್ನ ಸಂಸ್ಥೆಗಳಿಗೆ ವಿಭಿನ್ನ ಅಗತ್ಯಗಳು, ಮೂಲಸೌಕರ್ಯ, ಅಪಾಯದ ಮಾದರಿಗಳು ಮತ್ತು ನಿರ್ವಹಣಾ ವಿಧಾನಗಳಿರುತ್ತವೆ.

DigiMeld ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ಅನುಕೂಲಕರ ಮತ್ತು ಸಮರ್ಥನೀಯವಾದದ್ದು ಮತ್ತೊಬ್ಬ ಡೆವಲಪರ್‌ಗೆ ಅತ್ಯುತ್ತಮವಾಗಿರಬೇಕೆಂದಿಲ್ಲ.

ಆದರೂ, ತಾತ್ಕಾಲಿಕವಾಗಿ ಅಧಿಕಾರ ನೀಡುವ ತತ್ವ ಗಮನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ.

ಕೊನೆಯ ಮಾತಾಗಿ

ಹೊಸ ದೃಢೀಕರಣ ವಿಧಾನವನ್ನು ಆವಿಷ್ಕರಿಸಿದ್ದೇನೆಂದು ನಾನು ಭಾವಿಸುವುದರಿಂದ ಈ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿಲ್ಲ.

ಅಥವಾ ಮತ್ತೊಂದು ವ್ಯವಸ್ಥೆಯನ್ನು ಸಂಪೂರ್ಣ ಸುರಕ್ಷಿತವೆಂದು ಪರಿಚಯಿಸಲು ಬಯಸುವುದರಿಂದಲೂ ಅಲ್ಲ.

ಸಂಪೂರ್ಣ ಭದ್ರತೆ ಎಂಬುದೇ ಇಲ್ಲ.

ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವ ರೀತಿಯೇ ನನಗೆ ಆಸಕ್ತಿದಾಯಕವಾಗಿ ಕಾಣುತ್ತದೆ.

ಶಾಶ್ವತ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶವನ್ನು ಅನಂತವಾಗಿ ರಕ್ಷಿಸುವ ಬದಲು, ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿರಬೇಕಾದ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ಮರುಪರಿಶೀಲಿಸಬಹುದು.

ಅನೇಕ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಬದಲು — ತಾತ್ಕಾಲಿಕ ಅನುಮತಿಗಳನ್ನು ಬಳಸಬಹುದು.

ಮೊದಲ ದೃಢೀಕರಣದ ನಂತರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಂಬುವ ಬದಲು — ನಿರ್ದಿಷ್ಟ ಅಧಿಕಾರಗಳನ್ನು ನೀಡುವ ಮೊದಲು ದೃಢೀಕರಿಸಬಹುದು.

ಸೆಷನ್ ಮುಗಿಯುವವರೆಗೆ ಕಾಯುವ ಬದಲು — ಪ್ರವೇಶವನ್ನು ಕೇಂದ್ರೀಕೃತವಾಗಿ ಹಿಂಪಡೆಯುವ ವ್ಯವಸ್ಥೆ ಮಾಡಬಹುದು.

ಕೊನೆಗೆ, ಪ್ರತಿಯೊಂದು ಯೋಜನೆಗೂ ಪ್ರತ್ಯೇಕ ಪ್ರವೇಶ ವ್ಯವಸ್ಥೆ ನಿರ್ಮಿಸುವ ಬದಲು — ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸ್ವತಂತ್ರತೆಯನ್ನು ಉಳಿಸಿಕೊಂಡೇ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ನಿರ್ವಹಣೆಗೆ ಏಕೀಕೃತ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಬಹುದು.

ಇಂತಹ ವಿಧಾನದಿಂದ ಸಿಸ್ಟಮ್ ಹ್ಯಾಕ್ ಆಗುವ ಸಾಧ್ಯತೆ ಸಂಪೂರ್ಣವಾಗಿ ನಿವಾರಣೆಯಾಗುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳುವುದಿಲ್ಲ.

ಶಾಶ್ವತವಾಗಿ ಇರುವ ಖಾತೆ ವಿವರಗಳನ್ನು ರಕ್ಷಿಸುವುದರಿಂದ, ಅಧಿಕಾರಗಳನ್ನು ನಿಯಂತ್ರಿತವಾಗಿ ನೀಡುವುದು ಮತ್ತು ಹಿಂಪಡೆಯುವುದರ ಕಡೆಗೆ ಇದು ಗಮನವನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಕೆಲವೊಮ್ಮೆ ದಾಳಿಯ ಮೇಲ್ಮೈಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವೆಂದರೆ ಮತ್ತೊಂದು ರಕ್ಷಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಸೇರಿಸುವುದಲ್ಲ; ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅಗತ್ಯವಿಲ್ಲದ ಅಂಶವನ್ನೇ ತ್ಯಜಿಸುವುದಾಗಿರಬಹುದು.

ಈ ಆಲೋಚನೆಯಿಂದಲೇ ನನಗೆ MeldID Admin Gateway ಯ ಕಥೆ ಆರಂಭವಾಯಿತು.