AWS secret эргүүлэхдээ connection бүү тасал: хоёр хэрэглэгч ээлжлүүл

Өндөр хүртээмж шаарддаг өгөгдлийн сангийн credential-ийг AWS Secrets Manager-ээр автоматаар солихдоо Alternating users стратегийг ашиглаж болно. AWS-ийн rotation стратегийн тайлбар ёсоор нууц үг нь солигдож буй хэрэглэгчийн оронд нөгөө хэрэглэгчийн хүчинтэй credential-ийг авах боломжтой тул шинэ холболт татгалзах эрсдэл Single user горимоос бага. Харин ганц хэрэглэгчийн нууц үг өгөгдлийн санд солигдоод secret шинэчлэгдэх хүртэл богино завсар үүсдэг.

Энэ сонголт дангаараа тасалдалгүй ажиллагааг батлахгүй. Аппликейшн secret-ийн шинэ хувилбарыг авч, connection pool дахь credential-ээ шинэчилж, түр зуурын нэвтрэх алдаанд хязгаартай retry хийх ёстой. Хоёр хэрэглэгчийн эрх зөрвөл холболт амжилттай нээгдсэн ч хүссэн өгөгдлийн сангийн үйлдэл бүтэлгүйтэж болно.

Яагаад хоёр хэрэглэгч холболтын завсрыг багасгадаг вэ?

Single user эргэлтэд өгөгдлийн сангийн нууц үг түрүүлж солигдоход хуучин credential-ээр нээгдэх шинэ холболт татгалзагдаж болно. Аль хэдийн нээлттэй байгаа холболтыг нууц үгийн эргэлт автоматаар таслахгүй; эрсдэл нь голчлон дараа нь шинээр нэвтрэх оролдлогод хамаарна. Иймээс зөвхөн одоогийн session хэвийн байгаагаар үйлчилгээний бэлэн байдлыг дүгнэж болохгүй.

Alternating users горимд эхний эргэлтээр анхны хэрэглэгчийн хуулбар үүсэж, цаашид нууц үг нь ээлжлэн шинэчлэгдэнэ. Эргэлтийн үед secret авахад хүчинтэй credential буцаж ирэх бөгөөд эргэлт дууссаны дараа хоёр хэрэглэгчийн credential хүчинтэй байдаг. Гэхдээ нууц үгийн өөрчлөлт өгөгдлийн сангийн бүх серверт тархах хугацаатай орчинд шинэ credential-ээр нэвтрэх оролдлого түр татгалзагдах боломж үлдэнэ; retry-г аппликейшний талд шийдэх шалтгаан нь энэ.

Админ secret, Lambda болон сүлжээний замыг бэлтгэ

AWS-ийн Alternating users тохируулах заавар нь эргүүлэх аппликейшний credential болон хэрэглэгчийг хувилж, нууц үгийг нь өөрчлөх эрхтэй админ credential-ийг тусдаа secret-д хадгалдаг. Secrets Manager-ийн Lambda функц secret болон өгөгдлийн сан дахь өөрчлөлтийг гүйцэтгэнэ. Админ secret-ийг аппликейшнд уншуулах шаардлагагүй; түүнд хандах эрхийг rotation функцийн үүрэгт тохируул.

1. Эхний хэрэглэгчийн username, password, өгөгдлийн сангийн хаяг бодит холболтод тохирч байгааг шалга. Аппликейшний хэрэглэгчид шаардлагатай унших, бичих эрхийг л олго; админ эрхийг түүнд шилжүүлж болохгүй.
2. Automatic rotation-д Alternating users стратеги болон тусдаа superuser secret-ийг сонго. Эргэлтийн хуваарь, Lambda-ийн эрх, өгөгдлийн санд хүрэх security group-ийн дүрмийг хамтад нь тохируул.
3. Lambda өгөгдлийн сан болон Secrets Manager API-д хүрч байгааг шалга. Хувийн сүлжээ ашиглаж байвал Secrets Manager-ийн VPC endpoint шаардлагатай замыг хангаж байгаа эсэхийг үз; Amazon RDS-ийн удирддаг админ secret ашиглах үед RDS API-д хүрэх замыг мөн шалга.

Хуулбар хэрэглэгч үүсэхдээ анхны хэрэглэгчийн эрхийг авдаг. Дараа нь анхны хэрэглэгчийн эрхийг өөрчилсөн бол хуулбарын эрхийг тусад нь шинэчлэх хэрэгтэй. Schema, хүснэгт эсвэл role-ийн өөрчлөлтийн дараа хоёр username-аар аппликейшний бодит унших, бичих үйлдлийг шалгавал зөвхөн дараагийн ээлжинд илрэх эрхийн зөрүүг эрт олно.

Connection pool шинэ credential авах ёстой

Secret шинэчлэгдлээ гээд ажиллаж буй аппликейшний санах ой дахь username, password өөрөө солигдохгүй. Нээлттэй session үргэлжилж байсан ч pool шинэ холболт нээхдээ хадгалсан credential-ээ ашиглаж болно. Тиймээс credential-ийн cache хэзээ шинэчлэгдэх, AWSCURRENT хувилбарыг хэрхэн дахин авах, шинэ холболтыг аль pool-д оруулахыг аппликейшний тохиргоонд тодорхой болго.

Нэг хэрэглэгчийн хуучин credential эргэлтийн дараа ч хэсэг хугацаанд хүчинтэй байж болох тул алдаа шууд харагдахгүй. Дараагийн эргэлтэд тэр хэрэглэгчийн нууц үг солигдоход хуучин credential хадгалсан pool асуудал үүсгэнэ. Хуучин pool-ийг зогсоохдоо явж буй хүсэлтийг дуусгаж, шинэ хүсэлтийг шинэ credential-тэй pool рүү шилжүүлэх дарааллыг бэлтгэ.

Нэвтрэх алдаа гарвал эхлээд credential cache-ийг шинэчилж, дараа нь шинэ холболтоор хязгаартай retry хий. Хүлээлт болон нийт оролдлогын хугацааг үйлчилгээний timeout-д тааруулах нь давтан нэвтрэх хүсэлтээр өгөгдлийн санг ачаалахаас хамгаална. Retry-г бүх алдаанд адил хэрэглэхгүй: эрх хүрэхгүйгээс үүдсэн query алдаа шинэ нууц үг авснаар засрахгүй.

Эргэлтийг шинэ холболт, хоёр хэрэглэгчээр турш

Secret-ийн утга солигдсон эсэхийг шалгах нь аппликейшний ажиллагааны зөвхөн нэг хэсэг. Туршилтын орчинд эхний эргэлтээр хуулбар хэрэглэгч үүсэж, дараагийн эргэлтээр анхны хэрэглэгч шинэ credential авдгийг ажигла. Эргэлт бүрийн өмнө, явцад болон дараа нь AWSCURRENT-ээр шинэ холболт нээж үз; удаан ажилладаг session дангаараа шинэ нэвтрэлтийн алдааг илрүүлэхгүй.

1. Эргэлт эхлэхээс өмнөх шинэ холболтын амжилт, authentication алдаа болон pool шинэ холболт үүсгэх хугацааг тэмдэглэ. Үүнтэй эргэлтийн үеийн хэмжилтийг харьцуул.
2. Эргэлтийн явцад cache шинэчлэгдэх болон retry ажиллахыг ажигла. Зөвхөн Lambda амжилттай дууссанаар хэрэглэгчийн хүсэлт тасалдаагүй гэж үзэж болохгүй.
3. Эргэлтийн дараа хоёр username-аар аппликейшнд хэрэгтэй унших, бичих үйлдлийг тус тус гүйцэтгэ. Нэг хэрэглэгчээр амжилттай хийсэн SELECT нь нөгөөгийн эрх эсвэл бичих үйлдлийг батлахгүй.

Алдаа гарвал хүчинтэй credential-ийг тогтоож байж сэргээ

AWS-ийн rotation алдаа оношлох заавар CloudWatch дахь Lambda-ийн алхмууд, өгөгдлийн сан ба Secrets Manager-д хүрэх сүлжээ, мөн AWSCURRENT, AWSPENDING, AWSPREVIOUS хувилбаруудын хүчинтэй байдлыг шалгахыг зөвлөдөг. Эргэлт явж байхад secret-ийн төлөвийг гараар өөрчлөхөөс өмнө аль алхам зогссон, аль credential өгөгдлийн санд нэвтэрч байгааг тогтоо. Сүлжээний доголдол, дутуу эрх, credential-ийн зөрүүг ижил retry тохиргоогоор засах боломжгүй.

Аппликейшний deployment-ийг буцаах болон credential-ийн төлөвийг сэргээх ажиллагааг тусад нь төлөвлө. Өмнөх аппликейшний хувилбарыг дахин байршуулбал түүний cache-д байсан нууц үг автоматаар хүчинтэй болохгүй. AWSPREVIOUS-ийг ашиглахаас өмнө тухайн username, password өгөгдлийн санд нэвтэрч байгааг шалга; дараагийн эргэлтэд тэр хэрэглэгчийн нууц үг өөрчлөгдсөн байж болно. Хүчинтэй credential-ийг тогтоосны дараа pool-ийг шинэчилж, алдааны шалтгааныг зассаны дараа эргэлтийг дахин ажиллуул.

Мөн уншаарай:

• FTC OpenAI, Anthropic-ийг шалгаж эхлэв: агентын аюул хэрэглэгчийн хэрэг болов
• GitHub secret scanning олсон түлхүүрийг устгах нь оройтсон: эхлээд revoke хий
• AWS-ийн хөнгөлөлтөд шууд бүү түгж: ашиглаагүй цаг буцаад ирэхгүй