ಪ್ರವೇಶ ನಿಯಂತ್ರಣ, ಗುರುತು ಮತ್ತು ರಹಸ್ಯ ನಿರ್ವಹಣೆ

ಲಾಭಗಳು:

• ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಸಾಮರ್ಥ್ಯ ಮತ್ತು RBAC/ABAC ಜೊತೆಗೆ ಕನಿಷ್ಠ ಅಧಿಕಾರವನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ
• ಬಳಕೆದಾರರ ಸಂದರ್ಭದಲ್ಲಿ ಮಾದರಿಯನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ ಮಿಶ್ರ ಪ್ರಾಕ್ಸಿ ಅಪಾಯವನ್ನು ತಪ್ಪಿಸುವ ಸಾಮರ್ಥ್ಯ
• ರಹಸ್ಯ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ API ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ತಿರುಗಿಸುವ ಸಾಮರ್ಥ್ಯ

AI ವ್ಯವಸ್ಥೆಯ ಮೇಲಿನ ದಾಳಿಯ ಗಮನಾರ್ಹ ಭಾಗವು ಮಾದರಿಯನ್ನು "ಮೋಸಗೊಳಿಸುವಿಕೆ" ಯಿಂದ ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ, ಆದರೆ ಕದ್ದ API ಕೀ ಅಥವಾ ಅಧಿಕ-ಅಧಿಕೃತ ಖಾತೆಯೊಂದಿಗೆ. ಭದ್ರತೆಯ ಈ ಪದರವು ಶಾಸ್ತ್ರೀಯ ಮಾಹಿತಿ ಭದ್ರತೆಯಿಂದ ಬಂದಿದೆ, ಆದರೆ AI ಯ ಸಂದರ್ಭದಲ್ಲಿ ಹೊಸ ಅಪಾಯಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ: ಮಾದರಿಯು ಬೇರೊಬ್ಬರ ಪರವಾಗಿ ಸವಾರಿಯನ್ನು ಕರೆಯುತ್ತದೆ, ಸೇವಾ ಖಾತೆಯು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ, GitHub ಗೆ ಕೀಲಿಯು ಸೋರಿಕೆಯಾಗುತ್ತದೆ. ಈ ಘಟಕದಲ್ಲಿ, ದೃಢೀಕರಣ, ದೃಢೀಕರಣ (RBAC/ABAC), ಕನಿಷ್ಠ ದೃಢೀಕರಣ ಮತ್ತು ರಹಸ್ಯ ನಿರ್ವಹಣೆಯೊಂದಿಗೆ AI ಸಿಸ್ಟಮ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಹೇಗೆ ಕಿರಿದಾಗಿಸಬೇಕೆಂದು ನಾವು ಕಲಿಯುತ್ತೇವೆ.

ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ

ಎರಡು ಪದಗಳು ಹೆಚ್ಚಾಗಿ ಗೊಂದಲಕ್ಕೊಳಗಾಗುತ್ತವೆ:

• ದೃಢೀಕರಣ: "ನೀವು ಯಾರು?" — ಬಳಕೆದಾರ/ಸೇವೆಯು ನಿಜವಾಗಿಯೂ ಅವರು ಹೇಳಿಕೊಳ್ಳುವವರು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದು (ಪಾಸ್‌ವರ್ಡ್, ಟೋಕನ್, ಪ್ರಮಾಣಪತ್ರ, MFA).
• ಅಧಿಕಾರ: "ನೀವು ಏನು ಮಾಡಬಹುದು?" - ದೃಢೀಕರಿಸಿದ ಪಕ್ಷವು ಯಾವ ಸಂಪನ್ಮೂಲ/ಕ್ರಿಯೆಯನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.

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

ಎಚ್ಚರಿಕೆ: "ಗೊಂದಲಕ್ಕೊಳಗಾದ ಡೆಪ್ಯೂಟಿ" ಸಮಸ್ಯೆ: ಕಡಿಮೆ-ಅಧಿಕಾರದ ಬಳಕೆದಾರರು ಹೆಚ್ಚಿನ-ಅಧಿಕಾರದ ಮಾದರಿಯನ್ನು ಹೊರಗುತ್ತಿಗೆ ಮಾಡುವ ಮೂಲಕ ಅವರು ಪ್ರವೇಶಿಸಲಾಗದ ಡೇಟಾವನ್ನು ಪರೋಕ್ಷವಾಗಿ ಪ್ರವೇಶಿಸುತ್ತಾರೆ. ಮಾದರಿಯು ಯಾವಾಗಲೂ ಬಳಕೆದಾರರ ಅಧಿಕಾರದ ಸಂದರ್ಭದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, ಅವನ ಸ್ವಂತ ವಿಶಾಲ ಅಧಿಕಾರವಲ್ಲ.

RBAC ಮತ್ತು ABAC

• RBAC (ಪಾತ್ರ-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ): ಪ್ರವೇಶವು ಬಳಕೆದಾರರ ಪಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. "ಬೆಂಬಲ ತಜ್ಞರು" ಪಾತ್ರವು ಗ್ರಾಹಕರ ಟಿಪ್ಪಣಿಗಳನ್ನು ಓದಬಹುದು, ಆದರೆ ಅವುಗಳನ್ನು ಅಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸರಳ ಮತ್ತು ಸಾಮಾನ್ಯ.
• ABAC (ಗುಣಲಕ್ಷಣ-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ): ಪ್ರವೇಶವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ: ಬಳಕೆದಾರರ ವಿಭಾಗ, ಡೇಟಾದ ಗೌಪ್ಯತೆ ಲೇಬಲ್, ದಿನದ ಸಮಯ, ವಿನಂತಿಯು ಬರುವ ನೆಟ್‌ವರ್ಕ್. ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾದ ಆದರೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ.

ಹೆಚ್ಚಿನ ಸಂಸ್ಥೆಗಳು RBAC ಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಮತ್ತು ಸೂಕ್ಷ್ಮ ಡೇಟಾಕ್ಕಾಗಿ ABAC ಗೆ ಆಳವಾಗುತ್ತವೆ. AI ಗಾಗಿ ಹೆಬ್ಬೆರಳಿನ ನಿಯಮ: ಮಾದರಿಯು ಅದು ಕರೆ ಮಾಡುವ ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಮಾಡುವ ಬಳಕೆದಾರರ ಪಾತ್ರ/ಗುಣಲಕ್ಷಣಗಳ ಆಧಾರದ ಮೇಲೆ ಪ್ರವೇಶಿಸುವ ಪ್ರತಿಯೊಂದು ಡೇಟಾವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಬೇಕು.

ಹಂತ ಹಂತವಾಗಿ: ಕನಿಷ್ಠ ಅಧಿಕಾರವನ್ನು ಚಲಾಯಿಸುವುದು

1. ದಾಸ್ತಾನು ತೆಗೆದುಕೊಳ್ಳಿ. ಮಾದರಿಯು ಯಾವ ಸಾಧನಗಳನ್ನು ಕರೆಯುತ್ತದೆ, ಅದು ಯಾವ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ? ಅವೆಲ್ಲವನ್ನೂ ಪಟ್ಟಿ ಮಾಡಿ.
2. ಪ್ರತಿ ಪ್ರವೇಶವನ್ನು ಸಮರ್ಥಿಸಿ. "ಈ ಸಹಾಯಕನಿಗೆ ನಿಜವಾಗಿಯೂ ಅಳಿಸುವ ಅಧಿಕಾರ ಅಗತ್ಯವಿದೆಯೇ?" ಇಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ತೆಗೆದುಹಾಕಿ.
3. ಓದಲು-ಮಾತ್ರ ಡೀಫಾಲ್ಟ್. ಮಾದರಿಯು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ; ಪ್ರತ್ಯೇಕವಾದ, ಕಿರಿದಾದ-ವ್ಯಾಪ್ತಿಯ ಟೋಕನ್ ಬರೆಯುವ/ಅಳಿಸುವ ಅಗತ್ಯವಿದೆ.
4. ಬಳಕೆದಾರರ ಸಂದರ್ಭವನ್ನು ಸರಿಸಿ. ವಾಹನವನ್ನು ಬಳಕೆದಾರರ ಅಧಿಕಾರದೊಂದಿಗೆ ಕರೆ ಮಾಡಿ, ಸೇವಾ ಖಾತೆಯೊಂದಿಗೆ ಅಲ್ಲ.
5. ಅಲ್ಪಾವಧಿಯ ರುಜುವಾತು. ದೀರ್ಘಾವಧಿಯ ಕೀಗಳ ಬದಲಿಗೆ ಅಲ್ಪಾವಧಿಯ, ಸ್ವಯಂ-ನವೀಕರಿಸುವ ಟೋಕನ್ಗಳನ್ನು ಬಳಸಿ.

ರಹಸ್ಯ ನಿರ್ವಹಣೆ

API ಕೀ, ಪಾಸ್‌ವರ್ಡ್, ಟೋಕನ್ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರದಂತಹ ರಹಸ್ಯವಾಗಿ ಉಳಿಯಬೇಕಾದ ರುಜುವಾತುಗಳು ರಹಸ್ಯವಾಗಿದೆ. AI ಯೋಜನೆಗಳಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಅಪಘಾತವೆಂದರೆ ಮಾದರಿ ಪೂರೈಕೆದಾರರ API ಕೀಯನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಹುದುಗಿಸಿದಾಗ ಮತ್ತು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣಕ್ಕೆ (Git) ಸೋರಿಕೆಯಾಗುತ್ತದೆ.

ಸರಿಯಾದ ಅಪ್ಲಿಕೇಶನ್:

• ಕೋಡ್‌ನಲ್ಲಿ ಕೀಗಳನ್ನು ಎಂದಿಗೂ ಎಂಬೆಡ್ ಮಾಡಬೇಡಿ; ಪರಿಸರ ವೇರಿಯಬಲ್ ಅಥವಾ ರಹಸ್ಯ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿ (ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸುವ ಸೇವೆ).
• ತಿರುಗುವಿಕೆ: ನಿಯಮಿತ ಮಧ್ಯಂತರಗಳಲ್ಲಿ ಕೀಗಳನ್ನು ನವೀಕರಿಸಿ (ಉದಾಹರಣೆಗೆ ಪ್ರತಿ 90 ದಿನಗಳು); ಸೋರಿಕೆಯ ಅನುಮಾನವಿದ್ದಲ್ಲಿ, ತಕ್ಷಣವೇ ರದ್ದುಗೊಳಿಸಿ.
• ವ್ಯಾಪ್ತಿ ಕಡಿತ: ಪ್ರತಿ ಸ್ವಿಚ್ ಅಗತ್ಯವಿರುವ ಸೇವೆ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಅಧಿಕಾರವನ್ನು ಮಾತ್ರ ಹೊಂದಿದೆ.
• ಆಡಿಟ್: ಕೀಲಿಯನ್ನು ಯಾರು ಬಳಸಿದ್ದಾರೆ, ಯಾವಾಗ ಮತ್ತು ಎಲ್ಲಿ ಎಂದು ಲಾಗ್ ಮಾಡಿ.

ನಾಲ್ಕು ನಕಲು ಮಾಡಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್‌ಗಳು

ಪ್ರವೇಶ ಪರಿಶೀಲನೆ ನಿಯಂತ್ರಣ ಪ್ರಾಂಪ್ಟ್:

ಕೆಳಗಿನ ಪರಿಕರ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಉಪಕರಣಕ್ಕಾಗಿ, ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ:- ಈ ಸಹಾಯಕನ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸಲು ಈ ಉಪಕರಣದ ಅಗತ್ಯವಿದೆಯೇ? (ಹೌದು/ಇಲ್ಲ) - ಇದು ಓದಲು ಮಾತ್ರವೇ ಅಥವಾ ಬರೆಯುವುದು/ಅಳಿಸುವುದೇ? - ಈ ಉಪಕರಣವನ್ನು ಬಳಕೆದಾರರ ಅಧಿಕಾರ ಅಥವಾ ಸೇವಾ ಖಾತೆಯೊಂದಿಗೆ ಕರೆಯಲಾಗಿದೆಯೇ? ಅನವಶ್ಯಕ ಅಥವಾ ಅತಿಯಾಗಿ ಅಧಿಕೃತವಾದವುಗಳನ್ನು "ತೆಗೆದುಹಾಕು/ಮರುಮಾಡು" ಎಂದು ಗುರುತಿಸಿ.<tools>{{ tool_list }}</tools>

ರಹಸ್ಯ ಸೋರಿಕೆ ಸ್ಕ್ಯಾನಿಂಗ್ ಪ್ರಾಂಪ್ಟ್:

ಕೆಳಗಿನ ಕೋಡ್ ತುಣುಕಿನಲ್ಲಿ ಹಾರ್ಡ್‌ಕೋಡ್ ರಹಸ್ಯವಾಗಿರಬಹುದಾದ ಯಾವುದನ್ನಾದರೂ ಹುಡುಕಿ: API ಕೀ, ಪಾಸ್‌ವರ್ಡ್, ಟೋಕನ್, ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್, ಖಾಸಗಿ ಕೀ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸಾಲು ಮತ್ತು ಟೈಪ್ ನೀಡಿ. ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಮೌಲ್ಯವನ್ನು ನಕಲಿಸಿ;ಮುಖವಾಡ (ಮೊದಲ 4 ಅಕ್ಷರಗಳು + ***).<code>{{ source }}</code>

ಕನಿಷ್ಠ ಅಧಿಕಾರ ನಿರ್ಧಾರದ ನಿಯಮ:

ಹೊಸ ಪರಿಕರ/ಪ್ರವೇಶ ವಿನಂತಿ ಬಂದಾಗ, ಕೇಳಿ:1. ಈ ಪ್ರವೇಶವಿಲ್ಲದೆ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಬಹುದೇ? -> ಹೌದು ಎಂದಾದರೆ: REJECT2. ಓದು ಮಾತ್ರ ಸಾಕೇ? -> ಹೌದು ಎಂದಾದರೆ: GRANT ಬರೆಯಲು ಅನುಮತಿ3. ವ್ಯಾಪ್ತಿಯನ್ನು ಒಂದೇ ಮೂಲಕ್ಕೆ ಸಂಕುಚಿತಗೊಳಿಸಬಹುದೇ? -> ಹೌದು ಎಂದಾದರೆ: darat ಡೀಫಾಲ್ಟ್ ಉತ್ತರ "ಇಲ್ಲ"; ಪ್ರವೇಶವನ್ನು ಕಾರಣದಿಂದ ಪಡೆಯಲಾಗುತ್ತದೆ.

ತಿರುಗುವಿಕೆ ಕ್ಯಾಲೆಂಡರ್ ಜ್ಞಾಪನೆ:

ಪ್ರತಿ ರಹಸ್ಯಕ್ಕಾಗಿ, ದಾಖಲೆ: ಮಾಲೀಕರು, ಸೃಷ್ಟಿ ದಿನಾಂಕ, ಮುಕ್ತಾಯ, ವ್ಯಾಪ್ತಿ. 90 ದಿನಗಳನ್ನು ಮೀರಿದ ಅಥವಾ 30 ದಿನಗಳವರೆಗೆ ಬಳಸದೆ ಇರುವ ಯಾವುದೇ ಕೀಲಿಯನ್ನು "ತಿರುಗುವಿಕೆ/ರದ್ದುಗೊಳಿಸುವ ಅಭ್ಯರ್ಥಿ" ಎಂದು ವರದಿ ಮಾಡಿ.

ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್

ಕಳಪೆ ವಿಧಾನ

ಬಲವಾದ ವಿಧಾನ

ಒಂದೇ ಸೇವಾ ಖಾತೆಯೊಂದಿಗೆ ಮಾದರಿಯು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ

ವಿನಂತಿಯನ್ನು ಮಾಡುವ ಬಳಕೆದಾರರ ಅಧಿಕಾರದೊಂದಿಗೆ ಮಾದರಿಯು ಪ್ರವೇಶಿಸುತ್ತದೆ

API ಕೀಲಿಯನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಲಾಗಿದೆ, ಅದು ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ

ಪ್ರಮುಖ ರಹಸ್ಯ ವ್ಯವಸ್ಥಾಪಕದಲ್ಲಿ ತಿರುಗುವಿಕೆ, 90 ದಿನಗಳು

ಸಹಾಯಕನಿಗೆ ವಿಶಾಲವಾದ "ಏನಾದರೂ ಮಾಡು" ಅಧಿಕಾರ

ಓದಲು-ಮಾತ್ರ ಡೀಫಾಲ್ಟ್, ಸಂಕುಚಿತವಾಗಿ ಬರೆಯಿರಿ

ಪ್ರವೇಶಗಳನ್ನು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ

ನಿಯಮಿತ ಪ್ರವೇಶ ಪರಿಶೀಲನೆ ಮತ್ತು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವಿಕೆ

ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು

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

ಪ್ರಕರಣ 2 - ಲೀಕ್ಡ್ ಕೀ, 2 ವಾರಗಳಲ್ಲಿ 190,000 TL ಬಿಲ್. ಡೆವಲಪರ್ ಒಬ್ಬ ಹೆಲ್ಪರ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಮಾಡೆಲ್ API ಕೀಯನ್ನು ಎಂಬೆಡ್ ಮಾಡಿದ್ದಾನೆ ಮತ್ತು ಅದನ್ನು ಸಾರ್ವಜನಿಕ ರೆಪೊಸಿಟರಿಗೆ ತಳ್ಳಿದ್ದಾನೆ. ಬೋಟ್ 40 ನಿಮಿಷಗಳಲ್ಲಿ ಕೀಲಿಯನ್ನು ಕಂಡುಹಿಡಿದಿದೆ ಮತ್ತು ಅದನ್ನು ಎರಡು ವಾರಗಳವರೆಗೆ ಬಳಸಿತು; ಬಿಲ್ 190,000 TL ತಲುಪಿದೆ. ಕೀಲಿಯನ್ನು ರಹಸ್ಯ ವ್ಯವಸ್ಥಾಪಕರಿಗೆ ಸ್ಥಳಾಂತರಿಸಿದಾಗ, ತಿರುಗುವಿಕೆಗೆ ಸಂಪರ್ಕಪಡಿಸಿದಾಗ ಮತ್ತು ರೆಪೊಸಿಟರಿ ಸ್ಕ್ಯಾನಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿದಾಗ, ಘಟನೆಯು ಮರುಕಳಿಸಲಿಲ್ಲ.

ಪ್ರಕರಣ 3 - ಓದಲು-ಮಾತ್ರ ಡೀಫಾಲ್ಟ್ ಅಡಚಣೆಯನ್ನು ತಡೆಯುತ್ತದೆ. DevOps ಸಹಾಯಕರು ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಮೂಲಕ "ರೀಸೆಟ್ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್" ಆದೇಶವನ್ನು ಪಡೆದರು. ಆದಾಗ್ಯೂ, ಸಹಾಯಕನಿಗೆ ಓದಲು-ಮಾತ್ರ ಟೋಕನ್ ಮಾತ್ರ ನೀಡಲಾಯಿತು; ಬರೆಯುವುದು/ಅಳಿಸು ಪ್ರತ್ಯೇಕ ಅನುಮೋದಿತ ಹರಿವಿನಲ್ಲಿದೆ. ಅಧಿಕಾರ ದೋಷದೊಂದಿಗೆ ಆಜ್ಞೆಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಈವೆಂಟ್ ಅನ್ನು ಅಲಾರಂ ಆಗಿ ಲಾಗ್ ಮಾಡಲಾಗಿದೆ; ಯಾವುದೇ ಡೇಟಾ ನಷ್ಟವಾಗಿಲ್ಲ.

ಸಲಹೆ: ಹೊಸ ಪ್ರವೇಶ ವಿನಂತಿಗೆ ನಿಮ್ಮ ಡೀಫಾಲ್ಟ್ ಉತ್ತರವನ್ನು "ಇಲ್ಲ" ಮಾಡಿ. ಪ್ರವೇಶವು ಸಮರ್ಥನೆಯ ಮೂಲಕ ಪಡೆದ ಸಂಗತಿಯಾಗಿದೆ; ಎಲ್ಲರಿಗೂ ವಿಶಾಲವಾಗಿ ನೀಡುವುದು ಮತ್ತು ನಂತರ ಕಡಿತಗೊಳಿಸುವುದು ಬಹುತೇಕ ಎಂದಿಗೂ ಮಾಡಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅಪಾಯವು ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• ದೊಡ್ಡ ಸೇವಾ ಖಾತೆಯೊಂದಿಗೆ ಮಾದರಿಯನ್ನು ರನ್ ಮಾಡುವುದು ಮತ್ತು ಬಳಕೆದಾರರ ಸಂದರ್ಭವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು (ಮಿಶ್ರ ಪ್ರಾಕ್ಸಿ).
• ಕೋಡ್‌ನಲ್ಲಿ API ಕೀಯನ್ನು ಎಂಬೆಡ್ ಮಾಡುವುದು ಮತ್ತು ಅದನ್ನು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣಕ್ಕೆ ಸೋರಿಕೆ ಮಾಡುವುದು.
• ಕೀಲಿಗಳನ್ನು ತಿರುಗಿಸದಿರುವುದು ("ಕೆಲಸ ಮಾಡುವುದು, ಸ್ಪರ್ಶಿಸಬೇಡಿ").
• ಅಸಿಸ್ಟೆಂಟ್‌ಗೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಬರೆಯಲು/ಅಳಿಸಲು ಅನುಮತಿಗಳನ್ನು ನೀಡುವುದು.
• ಒಮ್ಮೆ ಪ್ರವೇಶವನ್ನು ನೀಡುವುದು ಮತ್ತು ಅದನ್ನು ಎಂದಿಗೂ ಮರುಪರಿಶೀಲಿಸುವುದಿಲ್ಲ.
• ದೃಢೀಕರಣದೊಂದಿಗೆ ದೃಢೀಕರಣವನ್ನು ಗೊಂದಲಗೊಳಿಸುವುದು ಮತ್ತು "ಅವನು ಲಾಗ್ ಇನ್ ಆಗಿದ್ದಾನೆ, ಅವನು ಎಲ್ಲವನ್ನೂ ಪ್ರವೇಶಿಸಬಹುದು" ಎಂದು ಊಹಿಸುವುದು.

ಸಾರಾಂಶದಲ್ಲಿ

• ದೃಢೀಕರಣವು "ನೀವು ಯಾರು" ಎಂಬ ಪ್ರಶ್ನೆಯಾಗಿದೆ, ದೃಢೀಕರಣವು "ನೀವು ಏನು ಮಾಡಬಹುದು" ಎಂಬ ಪ್ರಶ್ನೆಯಾಗಿದೆ; AI ನಲ್ಲಿ, ಎರಡೂ ಬಳಕೆದಾರರ ಸಂದರ್ಭದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು.
• ಮಾದರಿಯು ವಿನಂತಿಯನ್ನು ಮಾಡುವ ಬಳಕೆದಾರರ ಅಧಿಕಾರದೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, ತನ್ನದೇ ಆದ ವಿಶಾಲ ಅಧಿಕಾರದೊಂದಿಗೆ ಅಲ್ಲ (ಮಿಶ್ರ ಏಜೆನ್ಸಿಯ ಅಪಾಯವನ್ನು ತಪ್ಪಿಸುವುದು).
• RBAC ಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ, ಸೂಕ್ಷ್ಮ ಡೇಟಾದಲ್ಲಿ ABAC ನೊಂದಿಗೆ ಆಳಗೊಳಿಸಿ; ಕನಿಷ್ಠ ಅಧಿಕಾರವನ್ನು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಮಾಡಿ.
• ಕೋಡ್‌ನಲ್ಲಿ ರಹಸ್ಯಗಳನ್ನು ಹೂತುಹಾಕಬೇಡಿ; ಅದನ್ನು ರಹಸ್ಯ ನಿರ್ವಾಹಕದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ, ಅದನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿ ಮತ್ತು ನಿಯಮಿತ ತಿರುಗುವಿಕೆಗೆ ಇರಿಸಿ.
• ಓದಲು-ಮಾತ್ರ ಡೀಫಾಲ್ಟ್ ಮತ್ತು ಕಿರಿದಾದ ಬರಹವು ಚುಚ್ಚುಮದ್ದಿನ ಪರಿಣಾಮವನ್ನು ಹೆಚ್ಚು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

ನಿಮ್ಮ AI ಸಹಾಯಕ ಪ್ರವೇಶಿಸುವ ಎಲ್ಲಾ ಪರಿಕರಗಳು ಮತ್ತು ಡೇಟಾವನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಮೂರು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಿ: (1) ಇದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದೆಯೇ? (2) ಓದಲು ಮಾತ್ರ ಸಾಕೇ? (3) ಇದು ಬಳಕೆದಾರರ ಸಂದರ್ಭದಲ್ಲಿ ರನ್ ಆಗುತ್ತದೆಯೇ? ನಂತರ ಎಲ್ಲಾ ಹಾರ್ಡ್-ಕೋಡೆಡ್ ರಹಸ್ಯಗಳನ್ನು ಹುಡುಕಿ (ಮೇಲಿನ ಸ್ಕ್ಯಾನ್ ಪ್ರಾಂಪ್ಟ್ ಮೂಲಕ) ಮತ್ತು ನೀವು ಕಂಡುಕೊಳ್ಳುವ ಪ್ರತಿಯೊಂದು ಕೀಲಿಗಾಗಿ ತಿರುಗುವಿಕೆಯ ಯೋಜನೆಯನ್ನು ಬರೆಯಿರಿ. ಕನಿಷ್ಠ ಒಂದು ಅನಗತ್ಯ ಅಧಿಕಾರವನ್ನು ತೆಗೆದುಹಾಕಿ.

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ವಿನಂತಿಯನ್ನು ಮಾಡುವ ಬಳಕೆದಾರರ ಅಧಿಕಾರದ ಸಂದರ್ಭದಲ್ಲಿ ಮಾದರಿಯು ಚಲಿಸುತ್ತದೆ.
• [ ] ಉಪಕರಣ ಮತ್ತು ಡೇಟಾ ಪ್ರವೇಶವನ್ನು ಕನಿಷ್ಠ ಸವಲತ್ತು ತತ್ವಕ್ಕೆ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ.
• [ ] ಬರೆಯಲು/ಅಳಿಸುವಿಕೆಯು ಓದಲು-ಮಾತ್ರದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿದೆ, ಪ್ರಮಾಣೀಕರಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಸಂಕುಚಿತವಾಗಿದೆ.
• [ ] ಯಾವುದೇ ರಹಸ್ಯಗಳನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಹೂಳಲಾಗುವುದಿಲ್ಲ; ಇದನ್ನು ರಹಸ್ಯ ವ್ಯವಸ್ಥಾಪಕರಲ್ಲಿ ಇರಿಸಲಾಗಿದೆ.
• [ ] ಕೀಲಿಗಳಿಗಾಗಿ ತಿರುಗುವಿಕೆಯ ವೇಳಾಪಟ್ಟಿ ಮತ್ತು ರದ್ದತಿ ವಿಧಾನವಿದೆ.
• [ ] ಪ್ರವೇಶಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.