ଗିଟ୍‌ରେ ସିକ୍ରେଟ୍ସ (ଗୋପନୀୟ ତଥ୍ୟ): ଫାଇଲ୍ ଡିଲିଟ୍ କରିବା ଦ୍ୱାରା ଏହାର ସମାଧାନ କାହିଁକି ହୁଏନାହିଁ

ଏହି ସପ୍ତାହରେ କେହି ଜଣେ ମୋତେ ଏକ ବିରକ୍ତିକର ପ୍ରଶ୍ନ ପଚାରିଥିଲେ: "ସେହି ପ୍ରଡକ୍ସନ୍ କନ୍‌ଫିଗ୍ ଫାଇଲ୍ କେଉଁଠାରେ ଅଛି?" କୋଡିଏ ମିନିଟ୍ ପରେ ମୁଁ ଗିଟ୍ ରିପୋଜିଟୋରୀରେ ଥିବା ଏକ ଲାଇଭ୍ କ୍ଲାଉଡ୍ ଆକ୍ସେସ୍ କି (key) ଦେଖୁଥିଲି, ଯାହା ଟିମ୍‌ର ସମସ୍ତଙ୍କ ଦ୍ୱାରା ଏବଂ ଏହାକୁ କ୍ଲୋନ୍ କରିଥିବା ଯେକୌଣସି ବ୍ୟକ୍ତିଙ୍କ ଦ୍ୱାରା ପଢ଼ାଯାଇପାରିବ।

ଆଜି ହେଉଛି ସେପ୍ଟେମ୍ବର ୨୯, ୨୦୨୬, ଏବଂ ଏକ ବର୍ତ୍ତମାନର କାରଣ ପାଇଁ ଏହା ବାରମ୍ବାର ଘଟୁଛି। ବିଦ୍ୟମାନ ପ୍ରଡକ୍ଟଗୁଡ଼ିକରେ AI ଫିଚର୍‌ଗୁଡ଼ିକୁ ଯୋଡ଼ିବା ପାଇଁ ଟିମ୍‌ଗୁଡ଼ିକ ଦ୍ରୁତ ଗତିରେ ଆଗେଇ ଚାଲିଛନ୍ତି, ଏବଂ ପ୍ରତ୍ୟେକ ନୂଆ ଇଣ୍ଟିଗ୍ରେସନ୍ ଆଉ ଏକ କି (key) ଆଣିଥାଏ: ଏକ ମଡେଲ୍ API କି, ଏକ କ୍ଲାଉଡ୍ ସର୍ଭିସ୍ ଆକାଉଣ୍ଟ, ଏକ ଷ୍ଟୋରେଜ୍ କ୍ରେଡେନ୍ସିଆଲ୍। ସେହି କି (key) ଗୁଡ଼ିକ କେଉଁଠି ନା କେଉଁଠି ରହିବା ଆବଶ୍ୟକ, ଏବଂ ସବୁଠାରୁ ସହଜ ରାସ୍ତା ହେଉଛି ଆପ୍ଲିକେସନ୍‌ର କନ୍‌ଫିଗ୍ ଫାଇଲ୍। ଯଦି ସେହି ଫାଇଲ୍ ଗିଟ୍‌ରେ ପୂର୍ବରୁ ଟ୍ରାକ୍ ହେଉଛି, ତେବେ କେହି ଜଣେ କମିଟ୍ କରିବା ମାତ୍ରେ ସେହି ଗୋପନୀୟ ତଥ୍ୟ ପବ୍ଲିସ୍ ହୋଇଯାଏ।

ଏହି ପୋଷ୍ଟର ଉଦ୍ଦେଶ୍ୟ "ଗୋପନୀୟ ତଥ୍ୟ କମିଟ୍ କରନ୍ତୁ ନାହିଁ" ନୁହେଁ। ଏହା ସମସ୍ତେ ଜାଣନ୍ତି। ଉଦ୍ଦେଶ୍ୟ ହେଉଛି ଯେତେବେଳେ ଆପଣ ଗୋଟିଏ ଆବିଷ୍କାର କରନ୍ତି ସେତେବେଳେ କ'ଣ କରିବେ, କାରଣ ସ୍ୱାଭାବିକ ପ୍ରବୃତ୍ତିଟି ଭୁଲ୍ ଅଟେ।

ଏହା ଏକ ବିରକ୍ତିକର ପ୍ରଶ୍ନରୁ ଆରମ୍ଭ ହୋଇଥିଲା

ମୁଁ ଏକ .NET ଆପ୍ଲିକେସନ୍ ଦେଖୁଥିଲି। ପ୍ରଶ୍ନରେ ଥିବା କନ୍‌ଫିଗ୍ ଫାଇଲ୍ ଥିଲା appsettings.Production.json, ଯାହା ହେଉଛି ଷ୍ଟାଣ୍ଡାର୍ଡ ସ୍ଥାନ ଯେଉଁଠାରେ ଏକ .NET ଆପ୍ ନିଜର ପ୍ରଡକ୍ସନ୍ ସେଟିଂସ୍ ରଖେ। ପ୍ରଶ୍ନଟି କେବଳ ଥିଲା ଯେ କେଉଁ କପି ଅଧିକାରିକ ଥିଲା, କାରଣ ଫାଇଲ୍ ଏକାସାଙ୍ଗରେ ତିନୋଟି ଭିନ୍ନ ସ୍ଥାନରେ ଉପଲବ୍ଧ:

• ସୋର୍ସ ଟ୍ରିରେ, ରିପୋଜିଟୋରୀରେ
• ରନିଂ କଣ୍ଟେନର୍ ଭିତରେ, ଡିପ୍ଲଏଡ୍ ପାଥ୍‌ରେ
• ବିଲ୍ଡ ପାଇପଲାଇନ୍ ଦ୍ୱାରା ଡିପ୍ଲଏ ସମୟରେ ପୁନଃ ଲିଖିତ, ଯାହା ଡାଟାବେସ୍ କନେକ୍ସନ୍ ଷ୍ଟ୍ରିଙ୍ଗ୍ ଇଞ୍ଜେକ୍ଟ କରେ

ସେହି ତୃତୀୟଟି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। କାରଣ ପାଇପଲାଇନ୍ ଓଭରରାଇଟ୍ କରେ କିଛି ଡିପ୍ଲଏ ସମୟରେ ମୂଲ୍ୟଗୁଡ଼ିକ, ଏହା ମାନିନେବା ସହଜ ଯେ ଏହା ଓଭରରାଇଟ୍ କରେ ସମସ୍ତ ସେଗୁଡ଼ିକ ମଧ୍ୟରୁ। ଏହା ତାହା କରେ ନାହିଁ। ପାଇପଲାଇନ୍ ଯାହା ଇଞ୍ଜେକ୍ଟ କରେ ନାହିଁ ତାହା ଠିକ୍ କମିଟ୍ ହୋଇଥିବା ପରି ବ୍ୟବହାର କରାଯାଏ।

ଯାଞ୍ଚ କରିବାର ପ୍ରଥମ କଥା ହେଉଛି ଫାଇଲ୍ ଟ୍ରାକ୍ ହେଉଛି କି ନାହିଁ

ଏହା ଏକ ୱାନ୍-ଲାଇନ୍ ଚେକ୍ ଏବଂ ଆପଣ ଅନିଶ୍ଚିତ ଥିବା ଯେକୌଣସି କନ୍‌ଫିଗ୍ ଫାଇଲ୍ ଉପରେ ଏହାକୁ ଚଲାଇବା ଉଚିତ୍:

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

ଯଦି ସେହି କମାଣ୍ଡ ସଫଳ ହୁଏ, ତେବେ ଫାଇଲ୍ ଟ୍ରାକ୍ ହେଉଛି, ଯାହାର ଅର୍ଥ ଏହା ରିପୋଜିଟୋରୀ ଏବଂ ଏହାର ଇତିହାସରେ ଅଛି। ମୋ କ୍ଷେତ୍ରରେ ଏହା ସଫଳ ହେଲା, ଏବଂ .gitignore ରେ କନ୍‌ଫିଗ୍ ଫାଇଲ୍ ପାଇଁ ଆଦୌ କୌଣସି ନିୟମ ନଥିଲା।

ଏହା ଭିତରେ ପ୍ରାୟ ଏକ ଡଜନ ଗୋପନୀୟ ତଥ୍ୟ ଥିଲା: ଏକ ଡାଟାବେସ୍ କନେକ୍ସନ୍ ଷ୍ଟ୍ରିଙ୍ଗ୍, ଏକାଧିକ ପାସୱାର୍ଡ, ୱେବ୍ ପୁସ୍ ନୋଟିଫିକେସନ୍ କି (key), ଏକ AI ମଡେଲ୍ API କି, ଏବଂ ଏକ କ୍ଲାଉଡ୍ ଆକ୍ସେସ୍ କି ପେୟାର।

"ଆମେ କେବଳ ଏହାକୁ ଡିଲିଟ୍ କରିଦେବୁ" କାହିଁକି କାମ କରେ ନାହିଁ

ଏଠାରେ ସେହି ଅଂଶ ଅଛି ଯାହା ଲୋକଙ୍କୁ ଆଶ୍ଚର୍ଯ୍ୟ କରେ। ଏକ ଫାଇଲ୍‌ରୁ ଏକ ଗୋପନୀୟ ତଥ୍ୟ ଅପସାରଣ କରିବା ଏବଂ ସେହି ପରିବର୍ତ୍ତନକୁ କମିଟ୍ କରିବା ଦ୍ୱାରା ଗୋପନୀୟ ତଥ୍ୟ ଅପସାରିତ ହୁଏ ନାହିଁ।

ଗିଟ୍ କେବଳ ବର୍ତ୍ତମାନର ସ୍ଥିତି ନୁହେଁ, ବରଂ ଇତିହାସ ଷ୍ଟୋର୍ କରେ। ପୁରୁଣା କମିଟ୍ ଏବେ ବି ଅଛି। ଯେକେହି ଚଲାଇ ପାରିବେ:

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

ଏବଂ ମୂଳ ମୂଲ୍ୟଗୁଡ଼ିକ ପଢ଼ିପାରିବେ। ରିପୋଜିଟୋରୀର ପ୍ରତ୍ୟେକ କ୍୍ଲୋନ୍ ସେହି ସମ୍ପୂର୍ଣ୍ଣ ଇତିହାସକୁ ବହନ କରେ। ତେଣୁ ଗତ ବର୍ଷ ପ୍ରୋଜେକ୍ଟ କ୍ଲୋନ୍ କରିଥିବା ଜଣେ ଡେଭଲପର୍‌ଙ୍କ ଲାପଟପ୍‌ରେ ଆପଣ ଏହାକୁ "ରିମୁଭ୍" କରିବା ପରେ ମଧ୍ୟ ଆଜି ସେହି ଗୋପନୀୟ ତଥ୍ୟ ରହିଛି।

ଆପଣ ଏଥିପାଇଁ ତିଆରି ଟୁଲ୍ ସହିତ ଇତିହାସକୁ ପୁନଃ ଲିଖନ କରିପାରିବେ, କିନ୍ତୁ ଏଥିପାଇଁ ଏକ ଫୋର୍ସ ପୁସ୍ ଆବଶ୍ୟକ, ଏହା ପ୍ରତ୍ୟେକ ବିଦ୍ୟମାନ କ୍ଲୋନ୍‌କୁ ଭାଙ୍ଗିଦିଏ, ଏବଂ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ଭାବରେ ଲୋକଙ୍କ ପାଖରେ ପୂର୍ବରୁ ଥିବା କପିଗୁଡ଼ିକ ବିଷୟରେ ଏହା କିଛି କରେ ନାହିଁ। ଇତିହାସ ପୁନଃ ଲିଖନ ହେଉଛି କ୍ଲିନଅପ୍। ଏହା ପ୍ରତିକାର ନୁହେଁ।

ଏକମାତ୍ର କାର୍ଯ୍ୟ ଯାହା ପ୍ରକୃତରେ ଏକ୍ସପୋଜର୍‌କୁ ରଦ୍ଦ କରେ ତାହା ହେଉଛି ଗୋପନୀୟ ତଥ୍ୟକୁ ନିଜେ ପରିବର୍ତ୍ତନ କରିବା।

ପ୍ରକୃତରେ ଏହା କାହା ପାଖରେ ଅଛି ତାହା ଖୋଜନ୍ତୁ

ଏହା କେତେ ଜରୁରୀ ତାହା ସ୍ଥିର କରିବା ପୂର୍ବରୁ, ହୋଲ୍ଡରମାନଙ୍କୁ ସଚ୍ଚୋଟତାର ସହ ଗଣନ୍ତୁ। ଏକ ସାଧାରଣ ଛୋଟ ଟିମ୍‌ରେ ଏହି ତାଲିକାଟି ଦେଖାଯାଉଥିବା ଠାରୁ ଲମ୍ବା ହୋଇଥାଏ:

• ରିପୋଜିଟୋରୀ ଆକ୍ସେସ୍ ଥିବା ପ୍ରତ୍ୟେକ ବର୍ତ୍ତମାନର ଡେଭଲପର୍
• ପ୍ରତ୍ୟେକ ପୂର୍ବତନ ଡେଭଲପର୍ କିମ୍ବା କଣ୍ଟ୍ରାକ୍ଟର ଯିଏ କେବେ ଏହାକୁ କ୍ଲୋନ୍ କରିଥିଲେ, ଯାହାର ଲାପଟପ୍ ଆଉ ଆପଣଙ୍କ ନିୟନ୍ତ୍ରଣରେ ନାହିଁ
• ବିଲ୍ଡ ଏଜେଣ୍ଟ ୱାର୍କିଂ ଡିରେକ୍ଟୋରୀଗୁଡ଼ିକ ଏବଂ ସେମାନଙ୍କର କ୍ୟାସ୍
• ସର୍ଭର ଏବଂ ଭର୍ଚୁଆଲ୍ ମେସିନ୍ ବ୍ୟାକଅପ୍ ଏବଂ ସ୍ନାପସଟ୍
• ରିପୋଜିଟୋରୀର ଯେକୌଣସି ମିରର୍

ସେହି ଶେଷ ଗ୍ରୁପ୍‌କୁ ଭୁଲିଯିବା ସହଜ। ବ୍ୟାକଅପ୍‌ଗୁଡ଼ିକ ଟିକାଉ ହେବା ପାଇଁ ଡିଜାଇନ୍ କରାଯାଇଛି, ଯାହା ଏକ ଲିକ୍ ହୋଇଥିବା କ୍ରେଡେନ୍ସିଆଲ୍ ପାଇଁ ସମ୍ପୂର୍ଣ୍ଣ ଭୁଲ୍ ପ୍ରପର୍ଟି ଅଟେ।

ଏହି କି (key) ପ୍ରକୃତରେ କ'ଣ କରିପାରିବ ତାହା ଜାଣନ୍ତୁ

ଗମ୍ଭୀରତା ଏକ ଲିକ୍ ହେବାର ତଥ୍ୟ ବିଷୟରେ ନୁହେଁ। ଏହା ପ୍ରିଭିଲେଜ୍ ବିଷୟରେ। ଗୋଟିଏ ଷ୍ଟୋରେଜ୍ ବକେଟ୍ ପାଇଁ ଏକ ରିଡ୍-ଓନ୍ଲି କି ଏକ ଆଡମିନିଷ୍ଟ୍ରେଟିଭ୍ କି ଠାରୁ ଏକ ଭିନ୍ନ ସମସ୍ୟା ଅଟେ।

ଏଠାରେ ୟୁଜର୍ ଆକାଉଣ୍ଟର ନାମ ଏପରି ରଖାଯାଇଥିଲା ଯେପରି ଏହା କେବଳ ଏକ ଷ୍ଟୋରେଜ୍ ଆକାଉଣ୍ଟ। ତାହା ନଥିଲା। ଏହାର ପ୍ରକୃତ ପରମିସନ୍ ଯାଞ୍ଚ କରିବା ଏକ ଭିନ୍ନ କାହାଣୀ କହିଲା:

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

ଏହା ସେହି ସକାଳେ ବ୍ୟବହାର କରାଯାଇଥିଲା। ତେଣୁ କି (key) ଟି ଏକ ଭୁଲିଯାଇଥିବା ଅବଶିଷ୍ଟାଂଶ ନଥିଲା। ପ୍ରଡକ୍ସନ୍‌ରେ କିଛି ଜିନିଷ ଏହା ଉପରେ ନିର୍ଭର କରୁଥିଲା, ଯାହାର ଅର୍ଥ ହେଉଛି ଏହାକୁ ତୁରନ୍ତ ଡିଲିଟ୍ କରିବା ଦ୍ୱାରା ଏକ ଆଉଟେଜ୍ ହୋଇଥାନ୍ତା।

ରୋଟେଟ୍ କରନ୍ତୁ, କେବଳ ରିଭୋକ୍ କରନ୍ତୁ ନାହିଁ

ସେହି ଶେଷ ବିବରଣୀ ପ୍ଲାନ୍‌କୁ ବଦଳାଇଦିଏ। ଏକ ଲାଇଭ୍, ବ୍ୟବହାରରେ ଥିବା କ୍ରେଡେନ୍ସିଆଲ୍‌କୁ ଏକ ରୋଲଓଭର୍ ଦରକାର, ହଠାତ୍ ରିଭୋକ୍ ନୁହେଁ। ଏଠାରେ ସେହି କ୍ରମ ଦିଆଯାଇଛି ଯାହା ପ୍ରଡକ୍ସନ୍‌କୁ ନ ଭାଙ୍ଗି ଛିଦ୍ରକୁ ବନ୍ଦ କରେ।

ପଦକ୍ଷେପ ୧: କି (key) ଟି ଲାଇଭ୍ ଅଛି କି ନାହିଁ ନିଶ୍ଚିତ କରନ୍ତୁ ଏବଂ ଏହାର ବ୍ଲାଷ୍ଟ ରେଡିୟସ୍ ଖୋଜନ୍ତୁ

ଉପରେ ଥିବା ପରମିସନ୍ ଏବଂ ଶେଷ-ବ୍ୟବହୃତ ଚେକ୍‌ଗୁଡ଼ିକୁ ଚଲାନ୍ତୁ। କି (key) ଟି କ'ଣ କରିପାରିବ ସେଥିରୁ ଜରୁରୀକାଳୀନତା ସ୍ଥିର କରନ୍ତୁ, ଏହାର ନାମ କିପରି ଦିଆଯାଇଛି ସେଥିରୁ ନୁହେଁ।

ପଦକ୍ଷେପ ୨: ପ୍ରଥମଟି ସହିତ ଏକ ଦ୍ୱିତୀୟ କି ତିଆରି କରନ୍ତୁ

ଅଧିକାଂଶ କ୍ଲାଉଡ୍ ପ୍ରୋଭାଇଡର୍ ୟୁଜର୍ ପିଛା ଦୁଇଟି ଆକ୍ଟିଭ୍ ଆକ୍ସେସ୍ କି (key) ଅନୁମତି ଦିଅନ୍ତି ଯାହାଦ୍ୱାରା ଆପଣ ନିରାପଦରେ ରୋଲ୍ ଓଭର୍ କରିପାରିବେ।

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

ପୁରୁଣା କି (key) କୁ ଏବେ ଛୁଅନ୍ତୁ ନାହିଁ।

ପଦକ୍ଷେପ ୩: ନୂଆ କି (key) କୁ ଏପରି ଏକ ସ୍ଥାନରେ ରଖନ୍ତୁ ଯାହା ରିପୋଜିଟୋରୀ ନୁହେଁ

ଆପଣଙ୍କ ପାଇପଲାଇନ୍ ପୂର୍ବରୁ ବ୍ୟବହାର କରୁଥିବା ଯେକୌଣସି ସିକ୍ରେଟ୍ ଷ୍ଟୋର୍‌କୁ ଏହାକୁ ଘୁଞ୍ଚାନ୍ତୁ। ଅଧିକାଂଶ ଟିମ୍ ପାଖରେ ପୂର୍ବରୁ ଗୋଟିଏ ଥାଏ ଏବଂ କେବଳ ଏହାକୁ କ୍ରମାଗତ ଭାବରେ ବ୍ୟବହାର କରୁନାହାଁନ୍ତି। ବିଲ୍ଡରୁ ଏହାକୁ ରେଫରେନ୍ସ କରନ୍ତୁ ଯାହାଫଳରେ ଡିପ୍ଲଏ ସମୟରେ ମୂଲ୍ୟ ଇଞ୍ଜେକ୍ଟ ହୁଏ ଏବଂ କେବେବି ସୋର୍ସରେ ଲେଖାଯାଏ ନାହିଁ।

ପଦକ୍ଷେପ ୪: ଡିପ୍ଲଏ ଏବଂ ଯାଞ୍ଚ କରନ୍ତୁ

ରିଡିପ୍ଲଏ କରନ୍ତୁ, ତାପରେ କି (key) ବ୍ୟବହାର କରିଥିବା ଫଙ୍କସନ୍‌ଗୁଡ଼ିକ ଏବେ ବି କାମ କରୁଛି କି ନାହିଁ ନିଶ୍ଚିତ କରନ୍ତୁ। ମୋ କ୍ଷେତ୍ରରେ ଏହାର ଅର୍ଥ ହେଉଛି ଆଉଟବାଉଣ୍ଡ ଇମେଲ୍ ଏବଂ ଫାଇଲ୍ ଷ୍ଟୋରେଜ୍ ଯାଞ୍ଚ କରିବା। ଆପଣ ରିଭୋକ୍ କରିବା ପୂର୍ବରୁ ଯାଞ୍ଚ କରନ୍ତୁ, କେବେବି ପରେ ନୁହେଁ।

ପଦକ୍ଷେପ ୫: ପୁରୁଣା କି (key) କୁ ଡିଆକ୍ଟିଭେଟ୍ କରନ୍ତୁ

ପ୍ରଥମେ ଡିଲିଟ୍ କରିବା ବଦଳରେ ଡିଆକ୍ଟିଭେଟ୍ କରନ୍ତୁ, କାରଣ ଯଦି ଆପଣ କୌଣସି କଞ୍ଜ୍ୟୁମର୍‌କୁ ମିସ୍ କରିଛନ୍ତି ତେବେ ଡିଆକ୍ଟିଭେସନ୍ ତୁରନ୍ତ ରିଭର୍ସିବଲ୍ ହୋଇଥାଏ।

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

କିଛି ଦିନ ପାଇଁ ତ୍ରୁଟିଗୁଡ଼ିକ ଉପରେ ନଜର ରଖନ୍ତୁ, ତାପରେ ଏହାକୁ ଡିଲିଟ୍ କରନ୍ତୁ।

ପଦକ୍ଷେପ ୬: କେବଳ ବର୍ତ୍ତମାନ, ରିପୋଜିଟୋରୀ ସଫା କରନ୍ତୁ

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

ଏହି ପଦକ୍ଷେପଟି ଉଦ୍ଦେଶ୍ୟମୂଳକ ଭାବରେ ଶେଷରେ ରଖାଯାଇଛି। ଏହା ପରବର୍ତ୍ତୀ ଲିକ୍‌କୁ ରୋକିଥାଏ। ଏହା ଏହି ଲିକ୍‌କୁ ଠିକ୍ କରେ ନାହିଁ।

ପଦକ୍ଷେପ ୭: ଆପଣ ଏଠାରେ ଥିବାବେଳେ ପରମିସନ୍‌ଗୁଡ଼ିକୁ କଡ଼ାକଡ଼ି କରନ୍ତୁ

ଯଦି ଷ୍ଟୋରେଜ୍ ନାମକ ଏକ ଆକାଉଣ୍ଟର ଆପଣଙ୍କ ପ୍ରଡକ୍ସନ୍ କମ୍ପ୍ୟୁଟ୍ ଉପରେ ନିୟନ୍ତ୍ରଣ ଥିଲା, ତେବେ ତାହା ମଧ୍ୟ ଠିକ୍ କରନ୍ତୁ। ଏକ ଓଭର୍-ପ୍ରିଭିଲେଜ୍ଡ୍ କି (key) କୁ ରୋଟେଟ୍ କରିବା ଦ୍ୱାରା କେବଳ ଆପଣଙ୍କୁ ଏକ ନୂଆ ଓଭର୍-ପ୍ରିଭିଲେଜ୍ଡ୍ କି (key) ମିଳିଥାଏ।

ଉପସଂହାର

ଗିଟ୍‌ରେ ଏକ ଗୋପନୀୟ ତଥ୍ୟ ପାଇଲେ ସ୍ୱାଭାବିକ ପ୍ରବୃତ୍ତି ହେଉଛି ଏହାକୁ ଡିଲିଟ୍ କରିଦେବା ଏବଂ ଭଲ ଅନୁଭବ କରିବା। ସେହି ପ୍ରବୃତ୍ତି ଏକ ସଫା ଦେଖାଯାଉଥିବା ରିପୋଜିଟୋରୀ ଏବଂ ଏକ ଅପରିବର୍ତ୍ତିତ ବିପଦ ସୃଷ୍ଟି କରେ। ଇତିହାସ ସ୍ଥାୟୀ ଅଟେ, କ୍ଲୋନ୍‌ଗୁଡ଼ିକ ସବୁଆଡେ ଅଛି, ଏବଂ ଜିନିଷଗୁଡ଼ିକୁ ସବୁଦିନ ପାଇଁ ରଖିବା ପାଇଁ ବ୍ୟାକଅପ୍ ତିଆରି କରାଯାଇଛି। ଏକମାତ୍ର ଜିନିଷ ଯାହା ପ୍ରକୃତରେ ସାହାଯ୍ୟ କରେ ତାହା ହେଉଛି କ୍ରେଡେନ୍ସିଆଲ୍ ବଦଳାଇବା, ଏବଂ ଏହାକୁ ଏପରି କ୍ରମରେ କରିବା ଯାହା ରାସ୍ତାରେ ପ୍ରଡକ୍ସନ୍‌କୁ ଡାଉନ୍ କରେ ନାହିଁ। ଏହା ଲାଇଭ୍ ଅଛି କି ନାହିଁ ଯାଞ୍ଚ କରନ୍ତୁ, ଏହା କ'ଣ କରିପାରିବ ମାପନ୍ତୁ, ଏକ ନୂଆ କି (key) ରୋଲ୍ କରନ୍ତୁ, ଯାଞ୍ଚ କରନ୍ତୁ, ତାପରେ ପୁରୁଣାଟିକୁ ବନ୍ଦ କରନ୍ତୁ। ରିପୋଜିଟୋରୀ ସଫା କରିବା ହେଉଛି ଶେଷ ପଦକ୍ଷେପ, ପ୍ରଥମ ନୁହେଁ।

ଗୁଣ

• ଡିଟେକ୍ସନ୍ ଚେକ୍ ହେଉଛି ଗୋଟିଏ କମାଣ୍ଡ ଏବଂ ଯେକୌଣସି ରିପୋଜିଟୋରୀରେ କାମ କରେ
• ଫାଇଲ୍ ଡିଲିସନ୍ କିମ୍ବା ଇତିହାସ ପୁନଃ ଲିଖନ ବିପରୀତ, ରୋଟେସନ୍ ହେଉଛି ଏକ ସ୍ଥାୟୀ ସମାଧାନ
• ଦ୍ୱିତୀୟ କି (key) ସହିତ ରୋଲ୍ ଓଭର୍ କରିବା ଅର୍ଥ ଲାଇଭ୍ ସିଷ୍ଟମ୍ ପାଇଁ କୌଣସି ଡାଉନ୍‌ଟାଇମ୍ ନାହିଁ
• ରୋଟେସନ୍ ସମୟରେ ପରମିସନ୍‌ଗୁଡ଼ିକର ଅଡିଟିଂ ପ୍ରାୟତଃ ଓଭର୍-ପ୍ରିଭିଲେଜ୍ଡ୍ ଆକାଉଣ୍ଟଗୁଡ଼ିକୁ ପ୍ରକାଶ କରେ
• ଗୋପନୀୟ ତଥ୍ୟଗୁଡ଼ିକୁ ଏକ ବିଦ୍ୟମାନ ସିକ୍ରେଟ୍ ଷ୍ଟୋର୍‌କୁ ଘୁଞ୍ଚାଇବା ପାଇଁ ସାଧାରଣତଃ କୌଣସି ନୂଆ ଟୁଲିଂ ଆବଶ୍ୟକ ହୁଏ ନାହିଁ
• ଫାଇନାଲ୍ ଡିଲିଟ୍ ପର୍ଯ୍ୟନ୍ତ ସମ୍ପୂର୍ଣ୍ଣ ପ୍ରକ୍ରିୟାଟି ରିଭର୍ସିବଲ୍ ଅଟେ

ଦୋଷ

• ରୋଟେସନ୍ ପାଇଁ କି (key) ର ପ୍ରତ୍ୟେକ କଞ୍ଜ୍ୟୁମର୍ ଖୋଜିବା ଆବଶ୍ୟକ, ଯାହା କ୍ୱଚିତ୍ ଡକ୍ୟୁମେଣ୍ଟ୍ ହୋଇଥାଏ
• ଆପଣ ମୂଳ ଏକ୍ସପୋଜର୍‌କୁ ଅନଡୁ (undo) କରିପାରିବେ ନାହିଁ, କେବଳ ଏହାର ମୂଲ୍ୟ ସୀମିତ କରିପାରିବେ
• ଇତିହାସ ପୁନଃ ଲିଖନ ବିଦ୍ୟମାନ କ୍ଲୋନ୍‌ଗୁଡ଼ିକୁ ଭାଙ୍ଗିଦିଏ ଏବଂ ଟିମ୍ ପାଇଁ ବାଧାପ୍ରାପ୍ତ ଅଟେ
• ଲାପଟପ୍ ଏବଂ ବ୍ୟାକଅପ୍‌କୁ ପୂର୍ବରୁ କପି କରାଯାଇଥିବା ଗୋପନୀୟ ତଥ୍ୟ ଆପଣଙ୍କ ନିୟନ୍ତ୍ରଣ ବାହାରେ ଅଛି
• କ୍ଲିନଅପ୍ ଫିଚର୍ କାମ ସହିତ ସମୟ ପାଇଁ ପ୍ରତିଦ୍ୱନ୍ଦ୍ୱିତା କରେ ଏବଂ ସ୍ଥଗିତ ରଖିବା ସହଜ ଅଟେ
• କିଛି ପୁରୁଣା ସିଷ୍ଟମ୍ କ୍ରେଡେନ୍ସିଆଲ୍ ରୋଟେସନ୍‌କୁ ପ୍ରକୃତରେ ଅସୁବିଧାଜନକ କରିଥାଏ

ସତର୍କତା

ଏହି ଆର୍ଟିକିଲ୍‌ଟି ଶିକ୍ଷଣୀୟ ଅଟେ ଏବଂ ଆପଣଙ୍କ ପରିବେଶ ପାଇଁ ଏକ ପ୍ରେସକ୍ରିପ୍ସନ୍ ବଦଳରେ ଏକ ସାଧାରଣ ଆଭିମୁଖ୍ୟ ବର୍ଣ୍ଣନା କରେ। ଏଠାରେ ଥିବା ପ୍ରତ୍ୟେକ କମାଣ୍ଡ, ଫାଇଲ୍ ପାଥ୍, ଆକାଉଣ୍ଟ୍ ନାମ ଏବଂ କି ଆଇଡେଣ୍ଟିଫାୟର୍ ଏକ ପ୍ଲେସହୋଲ୍ଡର୍ ଅଟେ ଏବଂ ଏହାକୁ ଆପଣଙ୍କ ନିଜ ସିଷ୍ଟମ୍‌ରୁ ମୂଲ୍ୟ ସହିତ ବଦଳାଇବା ଆବଶ୍ୟକ। ଯଦି କୌଣସି କଞ୍ଜ୍ୟୁମର୍ ମିସ୍ ହୋଇଯାଏ ତେବେ କ୍ରେଡେନ୍ସିଆଲ୍ ରୋଟେଟିଂ ଲାଇଭ୍ ସର୍ଭିସ୍‌ଗୁଡ଼ିକୁ ବାଧା ଦେଇପାରେ, ତେଣୁ ପ୍ରଥମେ ଏକ ନନ୍-ପ୍ରଡକ୍ସନ୍ ପରିବେଶରେ ପ୍ରତ୍ୟେକ ପଦକ୍ଷେପ ଯାଞ୍ଚ କରନ୍ତୁ, ଏହାକୁ ଡିଆକ୍ଟିଭେଟ୍ କରିବା ପୂର୍ବରୁ ଏକ କି (key) ଉପରେ କ'ଣ ନିର୍ଭର କରେ ତାହା ନିଶ୍ଚିତ କରନ୍ତୁ, ଏବଂ ଏଠାରେ ଲେଖାଥିବା ଯେକୌଣସି ଜିନିଷ ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ ଆପଣଙ୍କ କ୍ଲାଉଡ୍ ପ୍ରୋଭାଇଡର୍ ଏବଂ ଟୁଲିଂ ପାଇଁ ସାମ୍ପ୍ରତିକ ଡକ୍ୟୁମେଣ୍ଟେସନ୍ ଯାଞ୍ଚ କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• ଗିଟ୍ ରିପୋଜିଟୋରୀରୁ ଏକ ଗୋପନୀୟ ତଥ୍ୟ ଡିଲିଟ୍ କରିବା ଦ୍ୱାରା ଏହା ଅପସାରିତ ହୁଏ କି? — ନା। ମୂଲ୍ୟ କମିଟ୍ ଇତିହାସରେ ଏବଂ ପ୍ରତ୍ୟେକ ବିଦ୍ୟମାନ କ୍ଲୋନ୍‌ରେ ରହିଥାଏ, ତେଣୁ ରିପୋଜିଟୋରୀ ଥିବା ଯେକେହି ମଧ୍ୟ ଏହାକୁ ପଢ଼ିପାରିବେ।
• ଏକ ଲିକ୍ ହୋଇଥିବା ଗୋପନୀୟ ତଥ୍ୟକୁ ଠିକ୍ କରିବା ପାଇଁ ଗିଟ୍ ଇତିହାସ ପୁନଃ ଲିଖନ ଯଥେଷ୍ଟ କି? — ନା। ଏହା ରିପୋଜିଟୋରୀକୁ ସଫା କରେ କିନ୍ତୁ ଲୋକମାନେ ପୂର୍ବରୁ କ୍ଲୋନ୍ କରିଥିବା କପିଗୁଡ଼ିକ ବିଷୟରେ କିଛି କରେ ନାହିଁ, ତେଣୁ କ୍ରେଡେନ୍ସିଆଲ୍ ଏବେ ବି ରୋଟେଟ୍ ହେବା ଆବଶ୍ୟକ।
• ଏକ କନ୍‌ଫିଗ୍ ଫାଇଲ୍ ଗିଟ୍ ଦ୍ୱାରା ଟ୍ରାକ୍ ହେଉଛି କି ନାହିଁ ମୁଁ କିପରି ଯାଞ୍ଚ କରିବି? — ରନ୍ କରନ୍ତୁ git ls-files --error-unmatch <path>। ଯଦି ଏହା ସଫଳ ହୁଏ, ତେବେ ଫାଇଲ୍ ଟ୍ରାକ୍ ହେଉଛି ଏବଂ ଏହାର ବିଷୟବସ୍ତୁ ଇତିହାସରେ ଅଛି।
• ମୁଁ କ'ଣ ଏକ ଲିକ୍ ହୋଇଥିବା କି (key) କୁ ତୁରନ୍ତ ଡିଲିଟ୍ କରିବା ଉଚିତ୍ କି? — କେବଳ ଯଦି ଏହା ବ୍ୟବହୃତ ହୋଇନଥାଏ। ଯଦି ପ୍ରଡକ୍ସନ୍‌ରେ କିଛି ଜିନିଷ ଏହା ଉପରେ ନିର୍ଭର କରେ, ତେବେ ପ୍ରଥମେ ଏକ ରିପ୍ଲେସମେଣ୍ଟ୍ ତିଆରି କରନ୍ତୁ, ଡିପ୍ଲଏ କରନ୍ତୁ, ଯାଞ୍ଚ କରନ୍ତୁ, ତାପରେ ପୁରୁଣାଟିକୁ ଡିଆକ୍ଟିଭେଟ୍ କରନ୍ତୁ।
• ଏକ ଲିକ୍ ହୋଇଥିବା କ୍ଲାଉଡ୍ କି (key) ଏବେ ବି ବ୍ୟବହାର ହେଉଛି କି ନାହିଁ ମୁଁ କିପରି ଜାଣିବି? — ଅଧିକାଂଶ ପ୍ରୋଭାଇଡର୍ ଆକ୍ସେସ୍ କି ପାଇଁ ଏକ ଶେଷ-ବ୍ୟବହୃତ ଟାଇମ୍‌ଷ୍ଟାମ୍ପ୍ ପ୍ରଦର୍ଶନ କରନ୍ତି, ଯାହା ଆପଣଙ୍କୁ କୁହେ ଯେ ଜଣେ କଞ୍ଜ୍ୟୁମର୍ ଏବେ ବି ଏହା ଉପରେ ନିର୍ଭର କରେ କି ନାହିଁ।
• ଏହା ବଦଳରେ ଆପ୍ଲିକେସନ୍ ଗୋପନୀୟ ତଥ୍ୟଗୁଡ଼ିକ କେଉଁଠାରେ ରହିବା ଉଚିତ୍? — ଏକ ସିକ୍ରେଟ୍ ଷ୍ଟୋର୍ କିମ୍ବା ଆପଣଙ୍କ ବିଲ୍ଡ ସିଷ୍ଟମ୍‌ର କ୍ରେଡେନ୍ସିଆଲ୍ ଷ୍ଟୋର୍‌ରେ, ଡିପ୍ଲଏ ସମୟରେ ଇଞ୍ଜେକ୍ଟ କରାଯାଏ ଯାହାଫଳରେ ମୂଲ୍ୟ କେବେବି ସୋର୍ସ କଣ୍ଟ୍ରୋଲ୍‌ରେ ଦେଖାଯାଏ ନାହିଁ।
• ଡିପ୍ଲୟମେଣ୍ଟ ପାଇପଲାଇନ୍ ଗୋପନୀୟ ତଥ୍ୟକୁ କାହିଁକି ସୁରକ୍ଷା ଦେଲାନାହିଁ? — ପାଇପଲାଇନ୍‌ଗୁଡ଼ିକ ପ୍ରାୟତଃ ଡାଟାବେସ୍ କନେକ୍ସନ୍ ଷ୍ଟ୍ରିଙ୍ଗ୍ ପରି କେବଳ କିଛି ସେଟିଂସ୍ ଇଞ୍ଜେକ୍ଟ କରିଥାଏ, ଏବଂ ଅନ୍ୟ ସମସ୍ତ ମୂଲ୍ୟକୁ ଠିକ୍ କମିଟ୍ ହୋଇଥିବା ପରି ଛାଡିଦିଏ।
• ମୁଁ ଏହାକୁ ପୁନର୍ବାର ଘଟିବାରୁ କିପରି ରୋକିପାରିବି? — କନ୍‌ଫିଗ୍ ଫାଇଲ୍‌ଗୁଡ଼ିକୁ ଯୋଡ଼ନ୍ତୁ .gitignoreରେ, ଆପଣଙ୍କ ରିପୋଜିଟୋରୀଗୁଡ଼ିକରେ ଅଟୋମେଟେଡ୍ ସିକ୍ରେଟ୍ ସ୍କାନିଂ ସକ୍ଷମ କରନ୍ତୁ, ଏବଂ ପରମିସନ୍‌ଗୁଡ଼ିକୁ ସମୀକ୍ଷା କରନ୍ତୁ ଯାହାଫଳରେ ଲିକ୍ ହୋଇଥିବା କି (key) ଗୁଡ଼ିକର ମୂଲ୍ୟ ଯଥାସମ୍ଭବ କମ୍ ହୋଇଥାଏ।

ଟ୍ୟାଗ୍

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