Git இல் உள்ள ரகசியங்கள்: கோப்பை நீக்குவது ஏன் அதை சரிசெய்யாது

இந்த வாரம் ஒருவர் என்னிடம் ஒரு சலிப்பான கேள்வியைக் கேட்டார்: "அந்த production config கோப்பு எங்கே இருக்கிறது?" இருபது நிமிடங்களுக்குப் பிறகு, Git ரெப்போசிட்டரியில் இருக்கும் ஒரு லைவ் கிளவுட் ஆக்சஸ் கீயை நான் பார்த்துக் கொண்டிருந்தேன், அதை அணியில் உள்ள அனைவரும் மற்றும் எப்போதாவது அதை குளோன் செய்த எவரும் படிக்க முடியும்.

இன்று செப்டம்பர் 29, 2026, தற்போதைய ஒரு காரணத்திற்காக இது தொடர்ந்து நடந்துகொண்டே இருக்கிறது. தற்போதைய தயாரிப்புகளில் AI அம்சங்களை இணைப்பதற்கு அணிகள் வேகமாக நகர்கின்றன, மேலும் ஒவ்வொரு புதிய ஒருங்கிணைப்பும் மற்றொரு கீயைக் கொண்டுவருகிறது: ஒரு மாடல் API கீ, ஒரு கிளவுட் சர்வீஸ் அக்கவுண்ட், ஒரு ஸ்டோரேஜ் கிரிடென்ஷியல். அந்த கீக்கள் எங்காவது இருக்க வேண்டும், மேலும் எளிதான வழி அப்ளிகேஷனின் config கோப்புதான். அந்த கோப்பு ஏற்கனவே Git இல் ட்ராக் செய்யப்பட்டிருந்தால், யாராவது கமிட் செய்தவுடனேயே அந்த ரகசியம் வெளியிடப்படும்.

இந்த பதிவின் நோக்கம் "ரகசியங்களை கமிட் செய்யாதீர்கள்" என்பது அல்ல. அது அனைவருக்கும் தெரியும். ஒன்றை நீங்கள் கண்டுபிடிக்கும்போது என்ன செய்ய வேண்டும் என்பதுதான் முக்கியம், ஏனென்றால் நாம் பொதுவாக நினைப்பது தவறானது.

இது ஒரு சலிப்பான கேள்வியுடன் தொடங்கியது

நான் ஒரு .NET அப்ளிகேஷனைப் பார்த்துக் கொண்டிருந்தேன். கேள்விக்குரிய config கோப்பு appsettings.Production.json, இது ஒரு .NET ஆப் அதன் production செட்டிங்ஸ்களை வைத்திருக்கும் நிலையான இடமாகும். எந்த நகல் அதிகாரப்பூர்வமானது என்பதுதான் எளிய கேள்வி, ஏனென்றால் கோப்பு ஒரே நேரத்தில் மூன்று வெவ்வேறு இடங்களில் உள்ளது:

• ரெப்போசிட்டரியில், சோர்ஸ் ட்ரீயில்
• டெப்ளாய் செய்யப்பட்ட பாதையில், இயங்கும் கண்டெய்னருக்கு உள்ளே
• டேட்டாபேஸ் கனெக்ஷன் ஸ்ட்ரிங்கை உட்செலுத்தும் பில்ட் பைப்லைனால் டெப்ளாய் நேரத்தில் மீண்டும் எழுதப்பட்டது

அந்த மூன்றாவது முக்கியமானது. ஏனென்றால் பைப்லைன் மேலெழுதுகிறது சில மதிப்புகளை டெப்ளாய் செய்யும்போது, அது மேலெழுதுகிறது என்று கருதுவது எளிது அனைத்து அவற்றையும். அது அவ்வாறு செய்வதில்லை. பைப்லைன் உட்செலுத்தாதவை அனைத்தும், கமிட் செய்யப்பட்டபடியே சரியாகப் பயன்படுத்தப்படும்.

கோப்பு ட்ராக் செய்யப்படுகிறதா என்பதை முதலில் சரிபார்க்க வேண்டும்

இது ஒரு ஒரு-வரி சரிபார்ப்பு, மேலும் உங்களுக்கு சந்தேகம் இருக்கும் எந்த config கோப்பிலும் இதை இயக்குவது மதிப்புக்குரியது:

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

அந்த கமாண்ட் வெற்றிகரமாக இருந்தால், கோப்பு ட்ராக் செய்யப்படுகிறது, அதாவது அது ரெப்போசிட்டரியிலும் அதன் வரலாற்றிலும் உள்ளது. என் விஷயத்தில் அது வெற்றிபெற்றது, மேலும் .gitignore config கோப்புகளுக்கு எந்த விதியும் இல்லை.

உள்ளே தோராயமாக ஒரு டஜன் ரகசியங்கள் இருந்தன: ஒரு டேட்டாபேஸ் கனெக்ஷன் ஸ்ட்ரிங், பல பாஸ்வேர்டுகள், வெப் புஷ் நோட்டிஃபிகேஷன் கீக்கள், ஒரு AI மாடல் API கீ, மற்றும் ஒரு கிளவுட் ஆக்சஸ் கீ ஜோடி.

"நாங்கள் அதை நீக்கிவிடுவோம்" என்பது ஏன் வேலை செய்யாது

இங்கேதான் மக்கள் ஆச்சரியப்படுகிறார்கள். ஒரு கோப்பிலிருந்து ஒரு ரகசியத்தை அகற்றி, அந்த மாற்றத்தை கமிட் செய்வது ரகசியத்தை அகற்றாது.

Git தற்போதைய நிலையை மட்டுமல்ல, வரலாற்றையும் சேமிக்கிறது. பழைய கமிட் இன்னும் உள்ளது. எவரும் இயக்கலாம்:

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

மற்றும் அசல் மதிப்புகளைப் படிக்கலாம். ரெப்போசிட்டரியின் ஒவ்வொரு குளோனும் அந்த முழு வரலாற்றையும் கொண்டுள்ளது. எனவே கடந்த ஆண்டு ப்ராஜெக்ட்டை குளோன் செய்த ஒரு டெவலப்பர், நீங்கள் அதை "அகற்றிய" பிறகும், இன்றும் தனது லேப்டாப்பில் அந்த ரகசியத்தை வைத்திருக்கிறார்.

அதற்காக உருவாக்கப்பட்ட டூல்களைப் பயன்படுத்தி நீங்கள் வரலாற்றை மீண்டும் எழுதலாம், ஆனால் அதற்கு ஒரு force push தேவைப்படுகிறது, இது தற்போதுள்ள ஒவ்வொரு குளோனையும் உடைக்கிறது, மேலும் விமர்சன ரீதியாக மக்கள் ஏற்கனவே வைத்திருக்கும் நகல்களைப் பற்றி அது எதுவும் செய்வதில்லை. வரலாற்றை மீண்டும் எழுதுவது என்பது சுத்தம் செய்வது (cleanup). அது தீர்வு (remediation) அல்ல.

வெளிப்பாட்டை (exposure) உண்மையில் ரத்து செய்யும் ஒரே செயல் ரகசியத்தையே மாற்றுவதுதான்.

உண்மையில் அதை யார் வைத்திருக்கிறார்கள் என்பதைக் கண்டறியவும்

இது எவ்வளவு அவசரம் என்பதை முடிவெடுப்பதற்கு முன், வைத்திருப்பவர்களை நேர்மையாக எண்ணுங்கள். ஒரு சாதாரண சிறிய அணியில் பட்டியல் தோன்றுவதை விட நீளமாக இருக்கும்:

• ரெப்போசிட்டரி ஆக்சஸ் உள்ள தற்போதைய ஒவ்வொரு டெவலப்பரும்
• எப்போதாவது அதைக் குளோன் செய்த ஒவ்வொரு முன்னாள் டெவலப்பர் அல்லது ஒப்பந்ததாரர், அவர்களின் லேப்டாப் உங்கள் கட்டுப்பாட்டில் இல்லை
• பில்ட் ஏஜென்ட் வொர்கிங் டைரக்டரிகள் மற்றும் அவற்றின் கேஷ்கள்
• சர்வர் மற்றும் விர்ச்சுவல் மெஷின் பேக்கப்கள் மற்றும் ஸ்னாப்ஷாட்கள்
• ரெப்போசிட்டரியின் ஏதேனும் மிரர்

கடைசி குழுவை மறப்பது எளிது. பேக்கப்கள் நீடித்திருக்கும் வகையில் வடிவமைக்கப்பட்டுள்ளன, கசிந்த கிரிடென்ஷியலுக்கு இது முற்றிலும் தவறான பண்பாகும்.

அந்த கீ உண்மையில் என்ன செய்ய முடியும் என்பதைக் கண்டறியவும்

தீவிரம் என்பது கசிவின் உண்மையை பற்றியது அல்ல. அது சலுகையைப் (privilege) பற்றியது. ஒரு ஸ்டோரேஜ் பக்கெட்டிற்கான read-only கீ என்பது ஒரு அட்மினிஸ்ட்ரேட்டிவ் கீயிலிருந்து மிகவும் வேறுபட்ட பிரச்சனையாகும்.

இங்குள்ள யூசர் அக்கவுண்ட் ஒரு ஸ்டோரேஜ்-ஒன்லி அக்கவுண்ட் போல பெயரிடப்பட்டது. அது அப்படி இல்லை. அதன் உண்மையான பெர்மிஷன்களைச் சரிபார்த்தது வேறு கதையைச் சொன்னது:

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

அது அன்றைய காலை பயன்படுத்தப்பட்டிருந்தது. எனவே அந்த கீ மறக்கப்பட்ட ஒன்று அல்ல. புரொடக்ஷனில் ஏதோ ஒன்று அதையே சார்ந்துள்ளது, அதாவது அதை உடனடியாக நீக்குவது தடையை (outage) ஏற்படுத்தியிருக்கும்.

Rotate செய்யுங்கள், வெறுமனே ரத்து (revoke) செய்ய வேண்டாம்

அந்த கடைசி விவரம் திட்டத்தை மாற்றுகிறது. லைவ் ஆக, பயன்பாட்டில் உள்ள ஒரு கிரிடென்ஷியலுக்கு ஒரு ரோல்ஓவர் தேவை, திடீர் ரத்து அல்ல. புரொடக்ஷனை உடைக்காமல் ஓட்டையை அடைக்கும் வரிசைமுறை இதோ.

படி 1: கீ லைவ் ஆக உள்ளதா என்பதை உறுதிசெய்து அதன் பாதிப்பு எல்லையை (blast radius) கண்டறியவும்

மேலே உள்ள பெர்மிஷன் மற்றும் கடைசியாக-பயன்படுத்தப்பட்ட சரிபார்ப்புகளை இயக்கவும். கீ எப்படி பெயரிடப்பட்டுள்ளது என்பதில் இருந்து அல்லாமல், அது என்ன செய்ய முடியும் என்பதில் இருந்து அவசரத்தை முடிவு செய்யுங்கள்.

படி 2: முதல் கீக்கு இணையாக இரண்டாவது கீயை உருவாக்கவும்

நீங்கள் பாதுகாப்பாக ரோல் ஓவர் செய்ய முடியும் என்பதற்காகவே, பெரும்பாலான கிளவுட் புரொவைடர்கள் ஒரு யூசருக்கு இரண்டு ஆக்டிவ் ஆக்சஸ் கீக்களை அனுமதிக்கின்றனர்.

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

பழைய கீயை இன்னும் தொட வேண்டாம்.

படி 3: புதிய கீயை ரெப்போசிட்டரி அல்லாத வேறு எங்காவது வைக்கவும்

உங்கள் பைப்லைன் ஏற்கனவே பயன்படுத்தும் எந்த சீக்ரெட் ஸ்டோருக்கும் அதை மாற்றவும். பெரும்பாலான அணிகள் ஏற்கனவே ஒன்றை வைத்துள்ளன, அதை தொடர்ந்து பயன்படுத்துவதில்லை. பில்டில் இருந்து அதைக் குறிப்பிடவும், இதனால் மதிப்பு டெப்ளாய் நேரத்தில் உட்செலுத்தப்படும் மற்றும் ஒருபோதும் சோர்ஸில் எழுதப்படாது.

படி 4: டெப்ளாய் மற்றும் சரிபார்ப்பு

மீண்டும் டெப்ளாய் செய்யவும், பின்னர் கீயைப் பயன்படுத்திய செயல்பாடுகள் இன்னும் வேலை செய்கின்றனவா என்பதை உறுதிப்படுத்தவும். என் விஷயத்தில் அது அவுட்பவுண்ட் மின்னஞ்சல் மற்றும் கோப்பு ஸ்டோரேஜை சரிபார்ப்பதைக் குறிக்கிறது. நீங்கள் ரத்து செய்வதற்கு முன் சரிபார்க்கவும், ஒருபோதும் அதற்குப் பிறகு அல்ல.

படி 5: பழைய கீயை டீஆக்டிவேட் செய்யவும்

முதலில் நீக்குவதற்குப் பதிலாக டீஆக்டிவேட் செய்யவும், ஏனென்றால் நீங்கள் ஒரு கன்ஸ்யூமரைத் தவறவிட்டிருந்தால் டீஆக்டிவேட் செய்வதை உடனடியாக மாற்றி அமைக்க (reverse) முடியும்.

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: நீங்கள் இங்கு இருக்கும்போது பெர்மிஷன்களை கடுமையாக்குங்கள்

ஸ்டோரேஜிற்காகப் பெயரிடப்பட்ட ஒரு அக்கவுண்ட் உங்கள் புரொடக்ஷன் கம்ப்யூட்டின் கட்டுப்பாட்டைக் கொண்டிருந்தால், அதையும் சரிசெய்யவும். அதிக-சலுகை (over-privileged) பெற்ற ஒரு கீயை Rotate செய்வது, ஒரு புதிய அதிக-சலுகை பெற்ற கீயை மட்டுமே உங்களுக்கு வழங்கும்.

முடிவுரை

Git இல் ஒரு ரகசியத்தை நீங்கள் கண்டுபிடிக்கும்போது அதை நீக்கிவிட்டு நிம்மதியாக உணர வேண்டும் என்பதுதான் உள்ளுணர்வு. அந்த உள்ளுணர்வு ஒரு சுத்தமாகத் தோன்றும் ரெப்போசிட்டரியையும் மாறாத ஆபத்தையுமே உருவாக்குகிறது. வரலாறு நிரந்தரமானது, குளோன்கள் எல்லா இடங்களிலும் உள்ளன, மற்றும் பேக்கப்கள் எல்லாவற்றையும் என்றென்றும் வைத்திருப்பதற்காகவே உருவாக்கப்பட்டுள்ளன. உண்மையிலேயே உதவுவது கிரிடென்ஷியலை மாற்றுவது மட்டுமே, மேலும் வழியில் புரொடக்ஷனைக் குறைக்காத ஒரு வரிசையில் அதைச் செய்வதுதான். அது லைவ் ஆக உள்ளதா எனச் சரிபார்க்கவும், அது என்ன செய்ய முடியும் என்பதை அளவிடவும், புதிய கீயை உள்ளிடவும், சரிபார்க்கவும், பின்னர் பழையதை அணைக்கவும். ரெப்போசிட்டரியைச் சுத்தம் செய்வது கடைசிப் படி, முதல் படி அல்ல.

நன்மைகள்

• கண்டறிதல் சரிபார்ப்பு ஒரு ஒற்றை கமாண்ட் ஆகும் மற்றும் எந்த ரெப்போசிட்டரியிலும் வேலை செய்கிறது
• கோப்பை நீக்குதல் அல்லது வரலாற்றை மீண்டும் எழுதுதல் போலல்லாமல், ரொட்டேஷன் ஒரு நிரந்தர தீர்வாகும்
• இரண்டாவது கீயுடன் ரோல் ஓவர் செய்வது என்பது லைவ் சிஸ்டம்களுக்கு டவுன்டைம் இல்லை என்பதாகும்
• ரொட்டேஷனின் போது பெர்மிஷன்களை தணிக்கை (Auditing) செய்வது, பெரும்பாலும் அதிக-சலுகை பெற்ற அக்கவுண்ட்களை வெளிப்படுத்துகிறது
• ஏற்கனவே உள்ள சீக்ரெட் ஸ்டோருக்குள் ரகசியங்களை நகர்த்துவதற்கு பொதுவாக எந்த புதிய டூலும் தேவையில்லை
• இறுதி நீக்கம் வரை முழு செயல்முறையும் மாற்றியமைக்கக்கூடியது (reversible)

குறைபாடுகள்

• ரொட்டேஷனுக்கு கீயின் ஒவ்வொரு கன்ஸ்யூமரையும் கண்டுபிடிக்க வேண்டும், இது அரிதாகவே ஆவணப்படுத்தப்பட்டுள்ளது
• அசல் வெளிப்பாட்டை நீங்கள் செயல்தவிர்க்க (undo) முடியாது, அதன் மதிப்பை மட்டுமே கட்டுப்படுத்த முடியும்
• வரலாற்றை மீண்டும் எழுதுவது தற்போதுள்ள குளோன்களை உடைக்கிறது மற்றும் அணிக்கு இடையூறு விளைவிக்கிறது
• லேப்டாப்கள் மற்றும் பேக்கப்களுக்கு ஏற்கனவே நகலெடுக்கப்பட்ட ரகசியங்கள் உங்கள் கட்டுப்பாட்டிற்கு அப்பாற்பட்டவை
• க்ளீனப் செய்வது ஃபீச்சர் வேலைகளுடன் நேரத்திற்காக போட்டியிடுகிறது மற்றும் அதைத் தள்ளிப்போடுவது எளிது
• சில பழைய சிஸ்டம்கள் கிரிடென்ஷியல் ரொட்டேஷனை உண்மையிலேயே கடினமாக்குகின்றன

எச்சரிக்கை

இந்த கட்டுரை கல்விக்கானது மற்றும் உங்கள் சூழலுக்கான ஒரு பரிந்துரையை விட, ஒரு பொதுவான அணுகுமுறையை விவரிக்கிறது. இங்குள்ள ஒவ்வொரு கமாண்ட், கோப்பு பாதை, அக்கவுண்ட் பெயர் மற்றும் கீ ஐடென்டிஃபையரும் ஒரு ப்ளேஸ்ஹோல்டராகும், மேலும் அவற்றை உங்கள் சொந்த சிஸ்டம்களின் மதிப்புகளுடன் மாற்ற வேண்டும். ஒரு கன்ஸ்யூமர் தவறவிடப்பட்டால், கிரிடென்ஷியல்களை Rotate செய்வது லைவ் சர்வீஸ்களுக்கு இடையூறு விளைவிக்கும், எனவே முதலில் ஒரு நான்-புரொடக்ஷன் சூழலில் ஒவ்வொரு படியையும் சரிபார்க்கவும், கீயை டீஆக்டிவேட் செய்வதற்கு முன் அதைச் சார்ந்திருப்பதை உறுதிப்படுத்தவும், மேலும் இங்கு எழுதப்பட்ட எதையும் நம்புவதற்கு முன்பு, உங்கள் கிளவுட் புரொவைடர் மற்றும் டூலிங்கிற்கான தற்போதைய ஆவணங்களைச் சரிபார்க்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• Git ரெப்போசிட்டரியிலிருந்து ஒரு ரகசியத்தை நீக்குவது அதை அகற்றுமா? — இல்லை. மதிப்பு கமிட் வரலாற்றிலும் மற்றும் தற்போதுள்ள ஒவ்வொரு குளோனிலும் தங்கியுள்ளது, எனவே ரெப்போசிட்டரி உள்ள எவரும் அதைத் தொடர்ந்து படிக்கலாம்.
• கசிந்த ரகசியத்தை சரிசெய்ய Git வரலாற்றை மீண்டும் எழுதுவது போதுமானதா? — இல்லை. இது ரெப்போசிட்டரியை சுத்தம் செய்கிறது ஆனால் மக்கள் ஏற்கனவே குளோன் செய்த நகல்களைப் பற்றி எதுவும் செய்வதில்லை, எனவே கிரிடென்ஷியல் இன்னும் Rotate செய்யப்பட வேண்டும்.
• ஒரு config கோப்பு Git ஆல் ட்ராக் செய்யப்படுகிறதா என்பதை நான் எவ்வாறு சரிபார்க்கலாம்? — இயக்கவும் git ls-files --error-unmatch <path>. அது வெற்றி பெற்றால், கோப்பு ட்ராக் செய்யப்படுகிறது மற்றும் அதன் உள்ளடக்கங்கள் வரலாற்றில் உள்ளன.
• கசிந்த கீயை நான் உடனடியாக நீக்க வேண்டுமா? — அது பயன்படுத்தப்படாமல் இருந்தால் மட்டுமே. புரொடக்ஷனில் ஏதேனும் ஒன்றை அது சார்ந்து இருந்தால், முதலில் ஒரு மாற்றீட்டை உருவாக்கவும், டெப்ளாய் செய்யவும், சரிபார்க்கவும், பின்னர் பழையதை டீஆக்டிவேட் செய்யவும்.
• கசிந்த கிளவுட் கீ இன்னும் பயன்படுத்தப்படுகிறதா என்பதை நான் எப்படி அறிவது? — பெரும்பாலான புரொவைடர்கள் ஆக்சஸ் கீகளுக்கான கடைசியாக பயன்படுத்தப்பட்ட டைம்ஸ்டாம்பை வெளிப்படுத்துகிறார்கள், இது ஒரு கன்ஸ்யூமர் இன்னும் அதைச் சார்ந்திருக்கிறாரா என்பதை உங்களுக்குத் தெரிவிக்கும்.
• மாறாக அப்ளிகேஷன் ரகசியங்கள் எங்கு இருக்க வேண்டும்? — ஒரு சீக்ரெட் ஸ்டோர் அல்லது உங்கள் பில்ட் சிஸ்டமின் கிரிடென்ஷியல் ஸ்டோரில், டெப்ளாய் நேரத்தில் உட்செலுத்தப்படும், எனவே மதிப்பு சோர்ஸ் கண்ட்ரோலில் ஒருபோதும் தோன்றாது.
• டெப்ளாய்மென்ட் பைப்லைன் ஏன் ரகசியத்தைப் பாதுகாக்கவில்லை? — பைப்லைன்கள் பெரும்பாலும் டேட்டாபேஸ் கனெக்ஷன் ஸ்ட்ரிங்குகள் போன்ற சில செட்டிங்ஸ்களை மட்டுமே உட்செலுத்துகின்றன, மேலும் மற்ற எல்லா மதிப்பையும் கமிட் செய்யப்பட்டபடியே விட்டுவிடுகின்றன.
• இது மீண்டும் நடப்பதை நான் எப்படித் தடுப்பது? — config கோப்புகளை இதில் சேர்க்கவும் .gitignore, உங்கள் ரெப்போசிட்டரிகளில் தானியங்கி சீக்ரெட் ஸ்கேனிங்கை எனேபிள் செய்யவும், மற்றும் பெர்மிஷன்களை மதிப்பாய்வு செய்யவும், இதனால் கசிந்த கீகளின் மதிப்பு முடிந்தவரை குறைவாக இருக்கும்.

குறிச்சொற்கள்

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