Git ನಲ್ಲಿ ಗುಪ್ತ ಪದಗಳು: ಫೈಲ್ ಅನ್ನು ಅಳಿಸುವುದರಿಂದ ಸಮಸ್ಯೆ ಏಕೆ ಬಗೆಹರಿಯುವುದಿಲ್ಲ

ಈ ವಾರ ಯಾರೋ ನನಗೆ ಒಂದು ಬೇಸರದ ಪ್ರಶ್ನೆ ಕೇಳಿದರು: "ಆ ಪ್ರೊಡಕ್ಷನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಎಲ್ಲಿದೆ?" ಇಪ್ಪತ್ತು ನಿಮಿಷಗಳ ನಂತರ ನಾನು Git ರೆಪೊಸಿಟರಿಯಲ್ಲಿರುವ ಲೈವ್ ಕ್ಲೌಡ್ ಆಕ್ಸೆಸ್ ಕೀಯನ್ನು ನೋಡುತ್ತಿದ್ದೆ, ಅದನ್ನು ತಂಡದ ಪ್ರತಿಯೊಬ್ಬರೂ ಮತ್ತು ಅದನ್ನು ಕ್ಲೋನ್ ಮಾಡಿದ ಯಾರು ಬೇಕಾದರೂ ಓದಬಹುದಿತ್ತು.

ಇಂದು ಸೆಪ್ಟೆಂಬರ್ 29, 2026, ಮತ್ತು ಪ್ರಸ್ತುತ ಕಾರಣವೊಂದಕ್ಕಾಗಿ ಇದು ಸಂಭವಿಸುತ್ತಲೇ ಇರುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಉತ್ಪನ್ನಗಳ ಮೇಲೆ AI ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಳವಡಿಸಲು ತಂಡಗಳು ವೇಗವಾಗಿ ಚಲಿಸುತ್ತಿವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದು ಹೊಸ ಇಂಟಿಗ್ರೇಶನ್ ಮತ್ತೊಂದು ಕೀಯನ್ನು ತರುತ್ತದೆ: ಮಾಡೆಲ್ API ಕೀ, ಕ್ಲೌಡ್ ಸರ್ವೀಸ್ ಅಕೌಂಟ್, ಸ್ಟೋರೇಜ್ ಕ್ರೆಡೆನ್ಶಿಯಲ್. ಆ ಕೀಗಳು ಎಲ್ಲೋ ಒಂದು ಕಡೆ ಇರಬೇಕು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅದಕ್ಕೆ ಸುಲಭವಾದ ದಾರಿಯಾಗಿದೆ. ಆ ಫೈಲ್ ಅನ್ನು ಈಗಾಗಲೇ Git ನಲ್ಲಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗಿದ್ದರೆ, ಯಾರಾದರೂ ಕಮಿಟ್ ಮಾಡಿದ ಕ್ಷಣದಲ್ಲಿಯೇ ಗುಪ್ತ ಪದ ಪ್ರಕಟವಾಗುತ್ತದೆ.

ಈ ಪೋಸ್ಟ್‌ನ ಉದ್ದೇಶವು "ಗುಪ್ತ ಪದಗಳನ್ನು ಕಮಿಟ್ ಮಾಡಬೇಡಿ" ಎಂಬುದಲ್ಲ. ಅದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ನೀವು ಅದನ್ನು ಕಂಡುಹಿಡಿದಾಗ ಏನು ಮಾಡಬೇಕು ಎಂಬುದು, ಏಕೆಂದರೆ ನಮ್ಮ ಸಹಜ ಪ್ರವೃತ್ತಿ ತಪ್ಪಾಗಿರುತ್ತದೆ.

ಇದು ಒಂದು ಬೇಸರದ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು

ನಾನು .NET ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೋಡುತ್ತಿದ್ದೆ. ಪ್ರಶ್ನೆಯಲ್ಲಿದ್ದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಇದಾಗಿತ್ತು appsettings.Production.json, ಇದು .NET ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಪ್ರೊಡಕ್ಷನ್ ಸೆಟ್ಟಿಂಗ್ಸ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಸ್ಥಳವಾಗಿದೆ. ಪ್ರಶ್ನೆ ಸರಳವಾಗಿತ್ತು - ಯಾವ ಕಾಪಿ ಅಧಿಕೃತವಾಗಿತ್ತು, ಏಕೆಂದರೆ ಫೈಲ್ ಒಂದೇ ಬಾರಿಗೆ ಮೂರು ವಿಭಿನ್ನ ಸ್ಥಳಗಳಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ:

• ಸೋರ್ಸ್ ಟ್ರೀನಲ್ಲಿ, ರೆಪೊಸಿಟರಿಯಲ್ಲಿ
• ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್ ಒಳಗೆ, ಡಿಪ್ಲಾಯ್ ಮಾಡಿದ ಪಾತ್‌ನಲ್ಲಿ
• ಡಿಪ್ಲಾಯ್ ಸಮಯದಲ್ಲಿ ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್‌ನಿಂದ ಮರುಬರೆಯಲ್ಪಟ್ಟಿದ್ದು, ಇದು ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡುತ್ತದೆ

ಆ ಮೂರನೆಯದು ಮುಖ್ಯವಾಗಿದೆ. ಏಕೆಂದರೆ ಪೈಪ್‌ಲೈನ್ ಓವರ್‌ರೈಟ್ ಮಾಡುತ್ತದೆ ಕೆಲವು ಮೌಲ್ಯಗಳನ್ನು ಡಿಪ್ಲಾಯ್ ಸಮಯದಲ್ಲಿ, ಇದು ಓವರ್‌ರೈಟ್ ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವುದು ಸುಲಭ ಎಲ್ಲವನ್ನೂ . ಆದರೆ ಹಾಗಾಗುವುದಿಲ್ಲ. ಪೈಪ್‌ಲೈನ್ ಇಂಜೆಕ್ಟ್ ಮಾಡದ ಯಾವುದೇ ವಿಷಯವನ್ನು ಕಮಿಟ್ ಮಾಡಿದಂತೆಯೇ ಬಳಸಲಾಗುತ್ತದೆ.

ಮೊದಲು ಪರಿಶೀಲಿಸಬೇಕಾದ ವಿಷಯವೆಂದರೆ ಫೈಲ್ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದು

ಇದು ಒಂದು-ಸಾಲಿನ ತಪಾಸಣೆಯಾಗಿದ್ದು, ನಿಮಗೆ ಖಚಿತವಿಲ್ಲದ ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಮೇಲೆ ರನ್ ಮಾಡಲು ಯೋಗ್ಯವಾಗಿದೆ:

git ls-files --error-unmatch path/to/appsettings.Production.json

ಆ ಕಮಾಂಡ್ ಯಶಸ್ವಿಯಾದರೆ, ಫೈಲ್ ಟ್ರ್ಯಾಕ್ ಆಗುತ್ತಿದೆ ಎಂದರ್ಥ, ಅಂದರೆ ಅದು ರೆಪೊಸಿಟರಿ ಮತ್ತು ಅದರ ಹಿಸ್ಟರಿಯಲ್ಲಿದೆ. ನನ್ನ ಪ್ರಕರಣದಲ್ಲಿ ಅದು ಯಶಸ್ವಿಯಾಯಿತು, ಮತ್ತು .gitignore ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಿಗೆ ಯಾವುದೇ ನಿಯಮ ಹೊಂದಿರಲಿಲ್ಲ.

ಇದರೊಳಗೆ ಸರಿಸುಮಾರು ಒಂದು ಡಜನ್ ಗುಪ್ತ ಪದಗಳಿದ್ದವು: ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಸ್ಟ್ರಿಂಗ್, ಹಲವಾರು ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ವೆಬ್ ಪುಶ್ ನೋಟಿಫಿಕೇಶನ್ ಕೀಗಳು, AI ಮಾಡೆಲ್ API ಕೀ, ಮತ್ತು ಕ್ಲೌಡ್ ಆಕ್ಸೆಸ್ ಕೀ ಪೇರ್.

"ನಾವು ಅದನ್ನು ಅಳಿಸುತ್ತೇವೆ" ಎಂಬುದು ಏಕೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ

ಜನರಿಗೆ ಆಶ್ಚರ್ಯ ತರುವ ಭಾಗ ಇಲ್ಲಿದೆ. ಫೈಲ್‌ನಿಂದ ಗುಪ್ತ ಪದವನ್ನು ತೆಗೆದುಹಾಕುವುದು ಮತ್ತು ಆ ಬದಲಾವಣೆಯನ್ನು ಕಮಿಟ್ ಮಾಡುವುದರಿಂದ ಗುಪ್ತ ಪದವು ಅಳಿಸಿಹೋಗುವುದಿಲ್ಲ.

Git ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಹಿಸ್ಟರಿಯನ್ನು ಸ್ಟೋರ್ ಮಾಡುತ್ತದೆ. ಹಳೆಯ ಕಮಿಟ್ ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ. ಯಾರು ಬೇಕಾದರೂ ರನ್ ಮಾಡಬಹುದು:

git log --oneline -- path/to/appsettings.Production.json
git show <old-commit>:path/to/appsettings.Production.json

ಮತ್ತು ಮೂಲ ಮೌಲ್ಯಗಳನ್ನು ಓದಬಹುದು. ರೆಪೊಸಿಟರಿಯ ಪ್ರತಿಯೊಂದು ಕ್ಲೋನ್ ಕೂಡ ಆ ಸಂಪೂರ್ಣ ಹಿಸ್ಟರಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆದ್ದರಿಂದ ಕಳೆದ ವರ್ಷ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಕ್ಲೋನ್ ಮಾಡಿದ ಡೆವಲಪರ್, ನೀವು ಅದನ್ನು "ತೆಗೆದುಹಾಕಿದ" ನಂತರವೂ, ಇಂದಿಗೂ ತಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಗುಪ್ತ ಪದವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.

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

ಎಕ್ಸ್‌ಪೋಶರ್ ಅನ್ನು ವಾಸ್ತವವಾಗಿ ರದ್ದುಗೊಳಿಸುವ ಏಕೈಕ ಕ್ರಮವೆಂದರೆ ಗುಪ್ತ ಪದವನ್ನೇ ಬದಲಾಯಿಸುವುದು.

ಅದು ನಿಜವಾಗಿಯೂ ಯಾರ ಬಳಿ ಇದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

ಇದು ಎಷ್ಟು ತುರ್ತು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು, ಹೊಂದಿರುವವರನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಎಣಿಸಿ. ಸಾಮಾನ್ಯ ಸಣ್ಣ ತಂಡದಲ್ಲಿ ಪಟ್ಟಿಯು ಕಾಣುವುದಕ್ಕಿಂತ ಉದ್ದವಾಗಿರುತ್ತದೆ:

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

ಆ ಕೊನೆಯ ಗುಂಪನ್ನು ಮರೆಯುವುದು ಸುಲಭ. ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಬಾಳಿಕೆ ಬರುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಸೋರಿಕೆಯಾದ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪು ಲಕ್ಷಣವಾಗಿದೆ.

ಆ ಕೀ ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡಬಲ್ಲದು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

ತೀವ್ರತೆಯು ಸೋರಿಕೆಯ ಸಂಗತಿಯ ಬಗ್ಗೆ ಅಲ್ಲ. ಅದು ಪ್ರಿವಿಲೇಜ್ ಬಗ್ಗೆ. ಒಂದು ಸ್ಟೋರೇಜ್ ಬಕೆಟ್‌ಗೆ ಇರುವ ರೀಡ್-ಓನ್ಲಿ ಕೀ, ಆಡ್ಮಿನಿಸ್ಟ್ರೇಟಿವ್ ಕೀಗಿಂತ ವಿಭಿನ್ನವಾದ ಸಮಸ್ಯೆಯಾಗಿದೆ.

ಇಲ್ಲಿರುವ ಬಳಕೆದಾರ ಖಾತೆಗೆ ಸ್ಟೋರೇಜ್-ಓನ್ಲಿ ಅಕೌಂಟ್ ಎಂಬಂತೆ ಹೆಸರಿಡಲಾಗಿತ್ತು. ಅದು ಹಾಗಿರಲಿಲ್ಲ. ಅದರ ವಾಸ್ತವಿಕ ಪರ್ಮಿಶನ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ ಬೇರೆಯದೇ ಕಥೆ ತಿಳಿಯಿತು:

aws iam list-attached-user-policies --user-name app-s3
aws iam list-user-policies        --user-name app-s3
aws iam list-groups-for-user      --user-name app-s3

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

ನಂತರ, ನಿಮ್ಮ ಟೈಮ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಧರಿಸುವ ಪ್ರಶ್ನೆ:

aws iam get-access-key-last-used --access-key-id AKIAEXAMPLEKEYID

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

ರೊಟೇಟ್ ಮಾಡಿ, ಕೇವಲ ರದ್ದುಗೊಳಿಸಬೇಡಿ

ಆ ಕೊನೆಯ ವಿವರವು ಯೋಜನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಲೈವ್ ಆಗಿರುವ, ಬಳಕೆಯಲ್ಲಿರುವ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗೆ ರೋಲ್‌ಓವರ್ ಅಗತ್ಯವಿದೆ, ದಿಢೀರ್ ರದ್ದತಿಯಲ್ಲ. ಪ್ರೊಡಕ್ಷನ್ ಅನ್ನು ಬ್ರೇಕ್ ಮಾಡದೆ ಕೊರತೆಯನ್ನು ಮುಚ್ಚುವ ಅನುಕ್ರಮ ಇಲ್ಲಿದೆ.

ಹಂತ 1: ಕೀ ಲೈವ್ ಆಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ ಮತ್ತು ಅದರ ಬ್ಲಾಸ್ಟ್ ರೇಡಿಯಸ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ

ಮೇಲಿನ ಪರ್ಮಿಶನ್ ಮತ್ತು ಲಾಸ್ಟ್-ಯೂಸ್ಡ್ ತಪಾಸಣೆಗಳನ್ನು ರನ್ ಮಾಡಿ. ಕೀಗೆ ನೀಡಲಾದ ಹೆಸರಿನಿಂದಲ್ಲದೆ, ಅದು ಏನು ಮಾಡಬಲ್ಲದು ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ತುರ್ತನ್ನು ನಿರ್ಧರಿಸಿ.

ಹಂತ 2: ಮೊದಲನೆಯದರ ಜೊತೆಗೆ ಎರಡನೇ ಕೀಯನ್ನು ರಚಿಸಿ

ಹೆಚ್ಚಿನ ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್‌ಗಳು ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ ಎರಡು ಸಕ್ರಿಯ ಆಕ್ಸೆಸ್ ಕೀಗಳನ್ನು ಅನುಮತಿಸುತ್ತಾರೆ, ಇದರಿಂದ ನೀವು ಸುರಕ್ಷಿತವಾಗಿ ರೋಲ್ ಓವರ್ ಮಾಡಬಹುದು.

aws iam create-access-key --user-name app-s3

ಹಳೆಯ ಕೀಯನ್ನು ಈಗಲೇ ಮುಟ್ಟಬೇಡಿ.

ಹಂತ 3: ಹೊಸ ಕೀಯನ್ನು ರೆಪೊಸಿಟರಿ ಹೊರತುಪಡಿಸಿ ಬೇರೆಲ್ಲಾದರೂ ಇರಿಸಿ

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

ಹಂತ 4: ಡಿಪ್ಲಾಯ್ ಮತ್ತು ಪರಿಶೀಲಿಸಿ

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

ಹಂತ 5: ಹಳೆಯ ಕೀಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ

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

aws iam update-access-key --user-name app-s3 --access-key-id AKIAEXAMPLEKEYID --status Inactive

ಕೆಲವು ದಿನಗಳವರೆಗೆ ಎರರ್‌ಗಳನ್ನು ಗಮನಿಸಿ, ನಂತರ ಅದನ್ನು ಅಳಿಸಿಹಾಕಿ.

ಹಂತ 6: ಈಗ ಮಾತ್ರ, ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೀನ್ ಮಾಡಿ

git rm --cached path/to/appsettings.Production.json
echo "appsettings.Production.json" >> .gitignore

ಈ ಹಂತವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕೊನೆಯಲ್ಲಿ ಇಡಲಾಗಿದೆ. ಇದು ಮುಂದಿನ ಸೋರಿಕೆಯನ್ನು ತಡೆಯುತ್ತದೆ. ಆದರೆ ಇದೇ ಸೋರಿಕೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಹಂತ 7: ನೀವು ಇಲ್ಲಿರುವಾಗಲೇ ಪರ್ಮಿಶನ್‌ಗಳನ್ನು ಬಿಗಿಗೊಳಿಸಿ

ಸ್ಟೋರೇಜ್ ಹೆಸರಿನ ಅಕೌಂಟ್ ನಿಮ್ಮ ಪ್ರೊಡಕ್ಷನ್ ಕಂಪ್ಯೂಟ್‌ನ ನಿಯಂತ್ರಣ ಹೊಂದಿದ್ದರೆ, ಅದನ್ನೂ ಸರಿಪಡಿಸಿ. ಓವರ್-ಪ್ರಿವಿಲೇಜ್ ಆಗಿರುವ ಕೀಯನ್ನು ರೊಟೇಟ್ ಮಾಡುವುದರಿಂದ ಕೇವಲ ಮತ್ತೊಂದು ಹೊಸ ಓವರ್-ಪ್ರಿವಿಲೇಜ್ ಕೀ ಸಿಗುತ್ತದೆ.

ತೀರ್ಮಾನ

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

ಅನುಕೂಲಗಳು

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

ಅನಾನುಕೂಲಗಳು

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

ಎಚ್ಚರಿಕೆ

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

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

• Git ರೆಪೊಸಿಟರಿಯಿಂದ ಗುಪ್ತ ಪದವನ್ನು ಅಳಿಸಿದರೆ ಅದು ಅಳಿಸಿಹೋಗುತ್ತದೆಯೇ? — ಇಲ್ಲ. ಮೌಲ್ಯವು ಕಮಿಟ್ ಹಿಸ್ಟರಿ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಕ್ಲೋನ್‌ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ರೆಪೊಸಿಟರಿಯನ್ನು ಹೊಂದಿರುವ ಯಾರು ಬೇಕಾದರೂ ಅದನ್ನು ಓದಬಹುದು.
• ಸೋರಿಕೆಯಾದ ಗುಪ್ತ ಪದವನ್ನು ಸರಿಪಡಿಸಲು Git ಹಿಸ್ಟರಿ ಮರುಬರೆದರೆ ಸಾಕಾಗುತ್ತದೆಯೇ? — ಇಲ್ಲ. ಇದು ರೆಪೊಸಿಟರಿಯನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತದೆ ಆದರೆ ಜನರು ಈಗಾಗಲೇ ಕ್ಲೋನ್ ಮಾಡಿದ ಕಾಪಿಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಅನ್ನು ಇನ್ನೂ ರೊಟೇಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
• ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು Git ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತಿದೆಯೇ ಎಂದು ನಾನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು? — ರನ್ ಮಾಡಿ git ls-files --error-unmatch <path>. ಅದು ಯಶಸ್ವಿಯಾದರೆ, ಫೈಲ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಅದರ ಕಂಟೆಂಟ್‌ಗಳು ಹಿಸ್ಟರಿಯಲ್ಲಿವೆ.
• ನಾನು ಸೋರಿಕೆಯಾದ ಕೀಯನ್ನು ತಕ್ಷಣವೇ ಅಳಿಸಬೇಕೇ? — ಅದು ಬಳಕೆಯಾಗದಿದ್ದರೆ ಮಾತ್ರ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಯಾವುದಾದರೂ ಅದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ, ಮೊದಲು ಬದಲಿ ಕೀಯನ್ನು ರಚಿಸಿ, ಡಿಪ್ಲಾಯ್ ಮಾಡಿ, ಪರಿಶೀಲಿಸಿ, ನಂತರ ಹಳೆಯದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ.
• ಸೋರಿಕೆಯಾದ ಕ್ಲೌಡ್ ಕೀಯನ್ನು ಇನ್ನೂ ಬಳಸಲಾಗುತ್ತಿದೆಯೇ ಎಂದು ನಾನು ಹೇಗೆ ತಿಳಿಯುವುದು? — ಹೆಚ್ಚಿನ ಪ್ರೊವೈಡರ್‌ಗಳು ಆಕ್ಸೆಸ್ ಕೀಗಳಿಗಾಗಿ ಲಾಸ್ಟ್-ಯೂಸ್ಡ್ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತಾರೆ, ಇದು ಕನ್ಸ್ಯೂಮರ್ ಇನ್ನೂ ಅದರ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಿದ್ದಾರೆಯೇ ಎಂದು ನಿಮಗೆ ತಿಳಿಸುತ್ತದೆ.
• ಅದರ ಬದಲಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಗುಪ್ತ ಪದಗಳು ಎಲ್ಲಿರಬೇಕು? — ಸೀಕ್ರೆಟ್ ಸ್ಟೋರ್ ಅಥವಾ ನಿಮ್ಮ ಬಿಲ್ಡ್ ಸಿಸ್ಟಮ್‌ನ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಸ್ಟೋರ್‌ನಲ್ಲಿ, ಮೌಲ್ಯವು ಸೋರ್ಸ್ ಕಂಟ್ರೋಲ್‌ನಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣಿಸದಂತೆ ಡಿಪ್ಲಾಯ್ ಸಮಯದಲ್ಲಿ ಇಂಜೆಕ್ಟ್ ಮಾಡಬೇಕು.
• ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್ ಪೈಪ್‌ಲೈನ್ ಗುಪ್ತ ಪದವನ್ನು ಏಕೆ ರಕ್ಷಿಸಲಿಲ್ಲ? — ಪೈಪ್‌ಲೈನ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಸ್ಟ್ರಿಂಗ್‌ಗಳಂತಹ ಕೆಲವು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮಾತ್ರ ಇಂಜೆಕ್ಟ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ಉಳಿದೆಲ್ಲ ಮೌಲ್ಯಗಳನ್ನು ಕಮಿಟ್ ಮಾಡಿದಂತೆಯೇ ಬಿಡುತ್ತವೆ.
• ಇದು ಮತ್ತೆ ಸಂಭವಿಸದಂತೆ ನಾನು ಹೇಗೆ ತಡೆಯಬಹುದು? — ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಸೇರಿಸಿ .gitignore, ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಆಟೊಮೇಟೆಡ್ ಸೀಕ್ರೆಟ್ ಸ್ಕ್ಯಾನಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ ಮತ್ತು ಪರ್ಮಿಶನ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಇದರಿಂದಾಗಿ ಸೋರಿಕೆಯಾದ ಕೀಗಳ ಮೌಲ್ಯವು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆಯಿರುತ್ತದೆ.

ಟ್ಯಾಗ್‌ಗಳು

#Security #DevOps #Git #SecretsManagement #CloudSecurity #IAM #KeyRotation #DevSecOps #ConfigManagement #InfrastructureAsCode