AWS bulutunda kaynak y\u00f6netimi yaparken hesaplar aras\u0131 operasyonlar ka\u00e7\u0131n\u0131lmaz hale gelir. Ancak bu esneklik, beraberinde ciddi g\u00fcvenlik riskleri de ta\u015f\u0131r. Bu makale, \u00f6zellikle AwsCustomResource kullan\u0131rken \u00e7apraz hesap eri\u015fimini Harici Kimlik (External ID) ile nas\u0131l g\u00fc\u00e7lendirebilece\u011finizi ad\u0131m ad\u0131m a\u00e7\u0131kl\u0131yor.<\/p>\n
Modern AWS altyap\u0131lar\u0131nda, farkl\u0131 i\u015f y\u00fckleri, departmanlar veya ortamlar (geli\u015ftirme, test, \u00fcretim) i\u00e7in birden fazla AWS hesab\u0131 kullanmak olduk\u00e7a yayg\u0131n bir yakla\u015f\u0131md\u0131r. Bu \u00e7oklu hesap stratejisi, kaynak izolasyonu, maliyet y\u00f6netimi ve g\u00fcvenlik kontrol\u00fc gibi pek \u00e7ok avantaj sunar. Ancak, bu hesaplar aras\u0131nda veri payla\u015f\u0131m\u0131, otomasyon veya merkezi y\u00f6netim gibi ihtiya\u00e7lar do\u011fdu\u011funda, \u00e7apraz hesap (cross-account) operasyonlar\u0131 devreye girer. \u00d6rne\u011fin, merkezi bir g\u00fcvenlik hesab\u0131, t\u00fcm \u00fcretim hesaplar\u0131na belirli g\u00fcvenlik politikalar\u0131n\u0131 da\u011f\u0131tmak isteyebilir veya bir CI\/CD boru hatt\u0131, farkl\u0131 bir hesaptaki kaynaklar\u0131 y\u00f6netmek zorunda kalabilir.<\/p>\n
Hesaplar aras\u0131 eri\u015fim, genellikle IAM Rolleri arac\u0131l\u0131\u011f\u0131yla sa\u011flan\u0131r. Bir hesap (g\u00fcvenilen hesap), ba\u015fka bir hesab\u0131n (g\u00fcvenen hesap) belirli bir IAM Rol\u00fcn\u00fc \u00fcstlenmesine (assume role) izin verir. Bu, kullan\u0131c\u0131lara veya servislere do\u011frudan kimlik bilgisi payla\u015fmak zorunda kalmadan ge\u00e7ici yetkiler tan\u0131r. Ancak, bu kolayl\u0131k beraberinde kritik bir g\u00fcvenlik riskini de getirir: “Confused Deputy” (Kafas\u0131 Kar\u0131\u015f\u0131k Vekil) sald\u0131r\u0131s\u0131.<\/p>\n
Confused Deputy sald\u0131r\u0131s\u0131, k\u00f6t\u00fc niyetli bir \u00fc\u00e7\u00fcnc\u00fc taraf\u0131n, asl\u0131nda kendisi i\u00e7in tasarlanmam\u0131\u015f bir hizmete, yetkilerini k\u00f6t\u00fcye kullanarak eri\u015fmeye \u00e7al\u0131\u015fmas\u0131 durumudur. \u00d6zellikle otomatikle\u015ftirilmi\u015f sistemlerde veya \u00fc\u00e7\u00fcnc\u00fc taraf entegrasyonlar\u0131nda bu risk daha da artar. AWS, bu t\u00fcr senaryolar\u0131n \u00f6n\u00fcne ge\u00e7mek i\u00e7in Harici Kimlik (External ID) kavram\u0131n\u0131 sunmu\u015ftur. Bu kimlik, rol \u00fcstlenme iste\u011fi s\u0131ras\u0131nda beklendi\u011fi gibi bir “s\u0131r” olarak i\u015flev g\u00f6rerek, g\u00fcvenli\u011fin temelini olu\u015fturur. Bu b\u00f6l\u00fcm\u00fcn ilerleyen k\u0131s\u0131mlar\u0131nda, Confused Deputy sald\u0131r\u0131s\u0131n\u0131 daha detayl\u0131 inceleyerek, neden Harici Kimlik kullan\u0131m\u0131n\u0131n kritik bir g\u00fcvenlik \u00f6nlemi oldu\u011funu daha iyi anlayaca\u011f\u0131z. Unutmamak gerekir ki, bir g\u00fcvenlik ihlali durumunda, etkilenen hesaplar\u0131n say\u0131s\u0131 ve etki alan\u0131, \u00e7oklu hesap mimarisinde katlanarak artabilir. Bu nedenle, \u00e7apraz hesap etkile\u015fimlerinde en kat\u0131 g\u00fcvenlik \u00f6nlemlerini uygulamak hayati \u00f6nem ta\u015f\u0131r.<\/p>\n
Confused Deputy sald\u0131r\u0131s\u0131, yetkili bir hizmetin veya kayna\u011f\u0131n, k\u00f6t\u00fc niyetli bir akt\u00f6r taraf\u0131ndan manip\u00fcle edilerek, asl\u0131nda o akt\u00f6r\u00fcn eri\u015fmemesi gereken bir kayna\u011fa eri\u015fmesini sa\u011flamas\u0131 durumudur. Senaryoyu daha iyi anlamak i\u00e7in somut bir \u00f6rnek d\u00fc\u015f\u00fcnelim: Diyelim ki A Hesab\u0131n\u0131z var ve B Hesab\u0131n\u0131zda kritik bir S3 kovas\u0131 var. A Hesab\u0131ndaki bir Lambda fonksiyonu (veya bizim konumuzda bir AwsCustomResource), B Hesab\u0131ndaki S3 kovas\u0131na eri\u015fmek i\u00e7in B Hesab\u0131nda tan\u0131ml\u0131 “MyCriticalBucketAccessRole” ad\u0131nda bir IAM Rol\u00fcn\u00fc \u00fcstleniyor (assume role). Bu rol\u00fcn Trust Policy’si, A Hesab\u0131ndaki Lambda’n\u0131n (veya Custom Resource’un) bu rol\u00fc \u00fcstlenmesine izin veriyor.<\/p>\n
\u015eimdi, e\u011fer k\u00f6t\u00fc niyetli bir kullan\u0131c\u0131 veya uygulama, A Hesab\u0131ndaki Lambda’y\u0131 kand\u0131rarak (\u00f6rne\u011fin, Lambda’ya g\u00f6nderdi\u011fi bir tetikleyici ile), asl\u0131nda eri\u015fmemesi gereken ba\u015fka bir S3 kovas\u0131na (C Hesab\u0131nda bulunan k\u00f6t\u00fc niyetli bir kullan\u0131c\u0131n\u0131n kovas\u0131) veri aktarmas\u0131n\u0131 sa\u011flarsa, i\u015fte bu bir Confused Deputy sald\u0131r\u0131s\u0131d\u0131r. Lambda, kendisine verilen talimatlar\u0131 yerine getirirken, fark\u0131nda olmadan k\u00f6t\u00fc niyetli bir akt\u00f6re hizmet etmi\u015f olur. Burada Lambda, yetkili olmas\u0131na ra\u011fmen “kafas\u0131 kar\u0131\u015fm\u0131\u015f” ve yanl\u0131\u015f bir ama\u00e7 i\u00e7in kullan\u0131lm\u0131\u015ft\u0131r.<\/p>\n
Bu sald\u0131r\u0131 t\u00fcr\u00fc, \u00f6zellikle iki farkl\u0131 taraf\u0131n (\u00f6rne\u011fin, sizin AWS hesab\u0131n\u0131z ve bir \u00fc\u00e7\u00fcnc\u00fc taraf SaaS uygulamas\u0131) IAM rolleri arac\u0131l\u0131\u011f\u0131yla etkile\u015fim kurdu\u011fu senaryolarda b\u00fcy\u00fck bir risk ta\u015f\u0131r. E\u011fer \u00fc\u00e7\u00fcnc\u00fc taraf bir servis sizin hesab\u0131n\u0131zda bir rol \u00fcstlenebiliyorsa ve bu rol\u00fcn Trust Policy’sinde bir k\u0131s\u0131tlama yoksa, o servis, kendi kullan\u0131c\u0131lar\u0131ndan gelen k\u00f6t\u00fc niyetli bir istekle sizin hesab\u0131n\u0131zdaki kaynaklara istenmeyen eylemler yapabilir. Harici Kimlik (External ID), bu t\u00fcr sald\u0131r\u0131lar\u0131 \u00f6nlemek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Trust Policy’ye bir External ID \u015fart\u0131 ekleyerek, rol \u00fcstlenmek isteyen taraf\u0131n, sizin belirledi\u011finiz gizli bir de\u011feri (External ID) sa\u011flamas\u0131n\u0131 zorunlu k\u0131lars\u0131n\u0131z. Bu de\u011fer yaln\u0131zca sizin taraf\u0131n\u0131zdan ve rol\u00fc \u00fcstlenmesi beklenen g\u00fcvenilir hizmet taraf\u0131ndan bilinir. B\u00f6ylece, k\u00f6t\u00fc niyetli bir akt\u00f6r, yetkili hizmeti kand\u0131rsa bile, bu gizli External ID’yi bilmedi\u011fi i\u00e7in rol\u00fc \u00fcstlenemez ve yetkisiz eri\u015fim sa\u011flanamaz. Bu mekanizma, \u00e7apraz hesap operasyonlar\u0131nda g\u00fcvenli\u011fin temel ta\u015flar\u0131ndan biridir.<\/p>\n
AWS ekosisteminde g\u00fcvenlik ve yetkilendirme, IAM (Identity and Access Management) servisinin temelini olu\u015fturur. IAM Rolleri, ge\u00e7ici yetkilendirme sa\u011flayarak, kullan\u0131c\u0131lar, uygulamalar veya AWS servisleri aras\u0131nda kimlik bilgilerini payla\u015fmadan g\u00fcvenli eri\u015fim imkan\u0131 sunar. Bir IAM Rol\u00fc, belirli eylemleri ger\u00e7ekle\u015ftirmesine izin verilen bir dizi izin politikas\u0131ndan olu\u015fur. En \u00f6nemli par\u00e7alar\u0131ndan biri ise “Trust Policy” (G\u00fcven Politikas\u0131)’dir. Bu politika, hangi varl\u0131klar\u0131n (\u00f6rne\u011fin, belirli bir AWS hesab\u0131, bir EC2 \u00f6rne\u011fi, bir Lambda fonksiyonu veya ba\u015fka bir IAM Rol\u00fc) bu rol\u00fc \u00fcstlenmesine izin verildi\u011fini tan\u0131mlar. Hesaplar aras\u0131 operasyonlarda, bir hesapta tan\u0131mlanan rol\u00fcn Trust Policy’si, ba\u015fka bir hesab\u0131n bu rol\u00fc \u00fcstlenmesine izin verecek \u015fekilde yap\u0131land\u0131r\u0131l\u0131r. Bu, yetki devrini g\u00fcvenli bir \u015fekilde y\u00f6netmek i\u00e7in kritik bir bile\u015fendir.<\/p>\n
Gelelim “Custom Resource” kavram\u0131na. AWS CloudFormation veya AWS CDK (Cloud Development Kit) gibi altyap\u0131 kodu (Infrastructure as Code – IaC) ara\u00e7lar\u0131, AWS kaynaklar\u0131n\u0131 deklaratif bir \u015fekilde tan\u0131mlaman\u0131za ve da\u011f\u0131tman\u0131za olanak tan\u0131r. Ancak, bazen CloudFormation’\u0131n do\u011frudan desteklemedi\u011fi belirli bir kayna\u011f\u0131 olu\u015fturman\u0131z, g\u00fcncellemeniz veya silmeniz gerekebilir. \u0130\u015fte tam bu noktada Custom Resource’lar devreye girer. Custom Resource, CloudFormation \u015fablonunuza \u00f6zel mant\u0131k eklemenizi sa\u011flayan bir mekanizmad\u0131r. Arka planda genellikle bir AWS Lambda fonksiyonu \u00e7al\u0131\u015ft\u0131r\u0131r. Bu Lambda fonksiyonu, CloudFormation’dan gelen olaylara (olu\u015fturma, g\u00fcncelleme, silme) yan\u0131t verir ve ilgili AWS API \u00e7a\u011fr\u0131lar\u0131n\u0131 yaparak \u00f6zel kayna\u011f\u0131n\u0131z\u0131 y\u00f6netir. \u00d6rne\u011fin, CloudFormation’da olmayan bir \u00fc\u00e7\u00fcnc\u00fc taraf API’yi \u00e7a\u011f\u0131rmak, bir veritaban\u0131nda \u00f6zel bir tablo olu\u015fturmak veya karma\u015f\u0131k bir yap\u0131land\u0131rma ad\u0131m\u0131 ger\u00e7ekle\u015ftirmek i\u00e7in Custom Resource kullanabilirsiniz.<\/p>\n
AwsCustomResource (ACR), AWS CDK’nin sundu\u011fu, \u00f6zel bir Custom Resource t\u00fcr\u00fcd\u00fcr. ACR, herhangi bir AWS API \u00e7a\u011fr\u0131s\u0131n\u0131 yapman\u0131z\u0131 sa\u011flayan bir yard\u0131mc\u0131 ara\u00e7t\u0131r. Normalde Custom Resource’lar i\u00e7in manuel olarak bir Lambda fonksiyonu yazman\u0131z ve bu fonksiyonun CloudFormation olaylar\u0131n\u0131 i\u015flemesini sa\u011flaman\u0131z gerekir. Ancak ACR, bu boilerplate kodu sizin i\u00e7in otomatik olarak olu\u015fturur. Tek yapman\u0131z gereken, ACR’ye hangi AWS API \u00e7a\u011fr\u0131s\u0131n\u0131 yapaca\u011f\u0131n\u0131 ve hangi parametreleri kullanaca\u011f\u0131n\u0131 belirtmektir. Bu, IaC ile otomasyonu \u00f6nemli \u00f6l\u00e7\u00fcde h\u0131zland\u0131r\u0131r ve CloudFormation’\u0131n do\u011fal yeteneklerini geni\u015fletir. \u00d6rne\u011fin, bir S3 kovas\u0131na bir object kopyalamak, bir SSM parametresini dinamik olarak ayarlamak veya ba\u015fka bir hesaptaki bir kayna\u011f\u0131n durumunu sorgulamak i\u00e7in ACR kullanabilirsiniz. Bu kolayl\u0131k, ACR’yi \u00e7apraz hesap operasyonlar\u0131nda da pop\u00fcler bir se\u00e7im haline getirir, ancak bu durumda g\u00fcvenlik mekanizmalar\u0131n\u0131 do\u011fru bir \u015fekilde uygulamak daha da \u00f6nem kazan\u0131r.<\/p>\n
AWS Cloud Development Kit (CDK), modern bulut altyap\u0131s\u0131 geli\u015ftirmenin merkezinde yer alan g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. Geli\u015ftiricilerin tan\u0131d\u0131k programlama dilleri (Python, TypeScript, Java vb.) kullanarak AWS kaynaklar\u0131n\u0131 kodla tan\u0131mlamas\u0131na olanak tan\u0131r. Bu “altyap\u0131 kodu” (Infrastructure as Code – IaC) yakla\u015f\u0131m\u0131, manuel yap\u0131land\u0131rma hatalar\u0131n\u0131 azalt\u0131r, tekrarlanabilirli\u011fi art\u0131r\u0131r ve s\u00fcr\u00fcm kontrol\u00fc ile i\u015fbirli\u011fini kolayla\u015ft\u0131r\u0131r. AWS CDK’nin sa\u011flad\u0131\u011f\u0131 y\u00fcksek soyutlama seviyesi, karma\u015f\u0131k bulut mimarilerini daha y\u00f6netilebilir hale getirir. Ancak, AWS hizmetlerinin ve \u00f6zelliklerinin \u00e7e\u015fitlili\u011fi g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, bazen CDK’nin veya CloudFormation’\u0131n do\u011frudan desteklemedi\u011fi \u00f6zel senaryolar ortaya \u00e7\u0131kabilir.<\/p>\n
\u0130\u015fte bu noktada AwsCustomResource (ACR) devreye girerek CDK’nin otomasyon g\u00fcc\u00fcn\u00fc bir ad\u0131m \u00f6teye ta\u015f\u0131r. ACR, temelinde bir Lambda fonksiyonu \u00e7al\u0131\u015ft\u0131ran bir CloudFormation Custom Resource’udur. Bu sayede, CDK geli\u015ftiricileri, CloudFormation’\u0131n do\u011frudan sunmad\u0131\u011f\u0131 herhangi bir AWS API \u00e7a\u011fr\u0131s\u0131n\u0131, da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinin bir par\u00e7as\u0131 olarak otomatik olarak ger\u00e7ekle\u015ftirebilirler. \u00d6rne\u011fin, bir EC2 instance’\u0131na belirli bir kullan\u0131c\u0131 verisi (user data) atamak, bir S3 kovas\u0131n\u0131n varsay\u0131lan \u015fifreleme ayarlar\u0131n\u0131 detayl\u0131ca yapmak, bir \u00fc\u00e7\u00fcnc\u00fc taraf API’yi entegre etmek veya hatta farkl\u0131 bir AWS hesab\u0131ndaki bir kayna\u011f\u0131n durumunu sorgulamak gibi g\u00f6revler ACR ile kolayca halledilebilir.<\/p>\n
Otomatikle\u015ftirme, sadece kaynak olu\u015fturma ve yap\u0131land\u0131rma s\u00fcre\u00e7lerini h\u0131zland\u0131rmakla kalmaz, ayn\u0131 zamanda insan hatas\u0131n\u0131 minimize eder. \u00d6zellikle \u00e7oklu hesap ortamlar\u0131nda, ayn\u0131 yap\u0131land\u0131rma veya eylemin birden fazla hesapta tutarl\u0131 bir \u015fekilde uygulanmas\u0131 gerekti\u011finde ACR’nin \u00f6nemi daha da artar. \u00d6rne\u011fin, merkezi bir g\u00fcvenlik hesab\u0131, t\u00fcm alt hesaplarda belirli CloudWatch log gruplar\u0131 olu\u015fturmak veya IAM rol politikalar\u0131n\u0131 g\u00fcncellemek i\u00e7in bir ACR kullanabilir. Bu, “tek do\u011fruluk kayna\u011f\u0131” prensibini benimseyerek, manuel yap\u0131land\u0131rmadan kaynaklanabilecek tutars\u0131zl\u0131klar\u0131 ve g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 ortadan kald\u0131r\u0131r. ACR, altyap\u0131n\u0131z\u0131n sadece bir par\u00e7as\u0131 olmakla kalmaz, ayn\u0131 zamanda DevOps s\u00fcre\u00e7lerinizin ve s\u00fcrekli teslimat (CI\/CD) boru hatlar\u0131n\u0131z\u0131n ayr\u0131lmaz bir par\u00e7as\u0131 haline gelir, b\u00f6ylece h\u0131zl\u0131, g\u00fcvenilir ve g\u00fcvenli da\u011f\u0131t\u0131mlar yapman\u0131za olanak tan\u0131r.<\/p>\n
Harici Kimlik (External ID), AWS IAM’in \u00e7apraz hesap eri\u015fim g\u00fcvenli\u011fini art\u0131ran kritik bir \u00f6zelli\u011fidir. En basit ifadeyle, bir IAM Rol\u00fcn\u00fc \u00fcstlenmek (assume role) i\u00e7in bir gereklilik olarak tan\u0131mlanan rastgele bir dize de\u011feridir. Bu de\u011fer, rol \u00fcstlenme iste\u011fi yapan taraf\u0131n, rol\u00fcn tan\u0131mland\u0131\u011f\u0131 hesap taraf\u0131ndan beklendi\u011fini kan\u0131tlayan bir “s\u0131r” veya “parola” g\u00f6revi g\u00f6r\u00fcr.<\/p>\n
Peki, Harici Kimlik tam olarak nas\u0131l \u00e7al\u0131\u015f\u0131r ve g\u00fcvenli\u011fi nas\u0131l sa\u011flar? Temel mekanizma, rol\u00fcn Trust Policy’sinde yatar. Bir IAM rol\u00fc olu\u015fturdu\u011funuzda veya g\u00fcncelledi\u011finizde, bu rol\u00fc kimlerin \u00fcstlenebilece\u011fini belirten bir Trust Policy tan\u0131mlars\u0131n\u0131z. Normalde bu politika, belirli bir AWS hesab\u0131n\u0131n veya bir IAM kullan\u0131c\u0131s\u0131n\u0131n\/rol\u00fcn\u00fcn bu rol\u00fc \u00fcstlenmesine izin verir. Ancak, bu tek ba\u015f\u0131na Confused Deputy sald\u0131r\u0131lar\u0131na kar\u015f\u0131 tam koruma sa\u011flamaz. Harici Kimlik ekledi\u011finizde, Trust Policy’ye “Condition” (\u015fart) blo\u011funda \u0130\u015fleyi\u015fi \u015f\u00f6yle a\u00e7\u0131klayabiliriz: Diyelim ki sizin AWS hesab\u0131n\u0131z (Hesap A), ba\u015fka bir AWS hesab\u0131ndaki (Hesap B) bir IAM rol\u00fcn\u00fc \u00fcstlenerek belirli i\u015flemleri yapacak. Hesap B’deki rol\u00fcn Trust Policy’si, Hesap A’n\u0131n bu rol\u00fc \u00fcstlenmesine izin verirken, ayn\u0131 zamanda belirli bir External ID’nin de sa\u011flanmas\u0131n\u0131 \u015fart ko\u015fuyor. Hesap A’dan rol \u00fcstlenme iste\u011fi geldi\u011finde, AWS STS (Security Token Service), iste\u011fi yapan\u0131n sa\u011flad\u0131\u011f\u0131 External ID’yi, Hesap B’deki rol\u00fcn Trust Policy’sindeki External ID ile kar\u015f\u0131la\u015ft\u0131r\u0131r. E\u011fer bu iki de\u011fer e\u015fle\u015firse, rol \u00fcstlenme i\u015flemi ba\u015far\u0131l\u0131 olur ve Hesap A ge\u00e7ici kimlik bilgilerini al\u0131r. E\u015fle\u015fmezse, istek reddedilir.<\/p>\n Bu mekanizma, Confused Deputy sald\u0131r\u0131s\u0131n\u0131 nas\u0131l \u00f6nler? K\u00f6t\u00fc niyetli bir \u00fc\u00e7\u00fcnc\u00fc taraf, Hesap A’daki yetkili bir servisi (\u00f6rne\u011fin, bir AwsCustomResource) manip\u00fcle ederek, Hesap B’deki rol\u00fc \u00fcstlenmesini sa\u011flamaya \u00e7al\u0131\u015fsa bile, bu \u00fc\u00e7\u00fcnc\u00fc taraf\u0131n Trust Policy’de belirtilen gizli External ID’yi bilmesi m\u00fcmk\u00fcn de\u011fildir. Dolay\u0131s\u0131yla, rol \u00fcstlenme iste\u011fi reddedilir ve k\u00f6t\u00fc niyetli eri\u015fim engellenir. Harici Kimlik, rol \u00fcstlenme iste\u011fi yapan\u0131n sadece “kim” oldu\u011funu (kimlik do\u011frulama), ayn\u0131 zamanda “bu rol\u00fc \u00fcstlenmesinin beklendi\u011fini” (niyet do\u011frulama) de kan\u0131tlamas\u0131n\u0131 sa\u011flayarak, ekstra bir g\u00fcvenlik katman\u0131 ekler. Bu, \u00f6zellikle \u00fc\u00e7\u00fcnc\u00fc taraf servislerin sizin hesab\u0131n\u0131zdaki rolleri \u00fcstlendi\u011fi veya kendi i\u00e7 \u00e7oklu hesap ortamlar\u0131n\u0131zda hassas i\u015flemler i\u00e7in otomasyon kulland\u0131\u011f\u0131n\u0131z senaryolarda hayati \u00f6neme sahiptir. Harici Kimlikler genellikle uzun, rastgele ve tahmin edilemez dizeler olmal\u0131d\u0131r ve d\u00fczenli olarak de\u011fi\u015ftirilmeleri (rotasyon) g\u00fcvenlik best practice’lerinden biridir. Bu sayede, s\u0131zma veya brute-force sald\u0131r\u0131lar\u0131na kar\u015f\u0131 diren\u00e7 daha da art\u0131r\u0131lm\u0131\u015f olur.<\/p>\n AwsCustomResource (ACR), AWS CDK ile CloudFormation’\u0131n yeteneklerini geni\u015fletmek i\u00e7in harika bir ara\u00e7 olsa da, \u00e7apraz hesap operasyonlar\u0131nda g\u00fcvenli\u011fi sa\u011flamak i\u00e7in Harici Kimlik (External ID) entegrasyonu kritik bir ad\u0131md\u0131r. ACR, temelinde bir Lambda fonksiyonu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131 i\u00e7in, bu Lambda’n\u0131n ba\u015fka bir hesaptaki bir rol\u00fc \u00fcstlenmesi gerekti\u011finde, bu rol\u00fcn Trust Policy’sine External ID \u015fart\u0131n\u0131 eklemeli ve ACR’nin bu External ID’yi sa\u011flayacak \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131n\u0131 sa\u011flamal\u0131y\u0131z. \u0130\u015fte ad\u0131m ad\u0131m bu entegrasyonu nas\u0131l ger\u00e7ekle\u015ftirece\u011finiz:<\/p>\n \u00d6ncelikle, senaryomuzu netle\u015ftirelim: Bir Kaynak Hesap<\/b> (Source Account) i\u00e7indeki bir AwsCustomResource, bir Hedef Hesap<\/b> (Target Account) i\u00e7indeki bir IAM rol\u00fcn\u00fc \u00fcstlenecek ve bu rol arac\u0131l\u0131\u011f\u0131yla Hedef Hesapta belirli bir AWS API \u00e7a\u011fr\u0131s\u0131 yapacak. Hedef Hesap’taki rol, g\u00fcvenlik amac\u0131yla bir External ID gerektirecek.<\/p>\n \u0130lk ad\u0131m, Hedef Hesap’ta AwsCustomResource’un \u00fcstlenece\u011fi IAM rol\u00fcn\u00fc olu\u015fturmak veya mevcut bir rol\u00fc g\u00fcncellemektir. Bu rol\u00fcn Trust Policy’si, Kaynak Hesap’taki AWS hesab\u0131n\u0131n rol\u00fc \u00fcstlenmesine izin vermeli ve bir <\/code><\/p>\n Yukar\u0131daki kod blo\u011funda:<\/p>\n \u015eimdi s\u0131ra Kaynak Hesap'a geldi. Burada, AwsCustomResource'u olu\u015fturaca\u011f\u0131z ve Hedef Hesap'taki rol\u00fc \u00fcstlenirken gerekli External ID'yi sa\u011flayacak \u015fekilde yap\u0131land\u0131raca\u011f\u0131z. AwsCustomResource, \u00e7a\u011fr\u0131lar\u0131 yaparken <\/code><\/p>\n Yukar\u0131daki kodda, \u00d6nemli Not:<\/strong> AwsCustomResource'un tek bir \u00e7a\u011fr\u0131 i\u00e7inde E\u011fer AwsCustomResource'un Lambda fonksiyonunun do\u011frudan Hedef Hesap'taki rol\u00fc \u00fcstlenmesini ve ard\u0131ndan bu rol ile bir API \u00e7a\u011fr\u0131s\u0131 yapmas\u0131n\u0131 istiyorsan\u0131z, Lambda'n\u0131n \u00e7al\u0131\u015fma zaman\u0131 kodunda Bu makale, AwsCustomResource'un arkas\u0131ndaki mekanizman\u0131n, yani Lambda'n\u0131n, bir rol\u00fc \u00fcstlenirken External ID'yi nas\u0131l kullanabilece\u011fini ve hedef rol\u00fcn nas\u0131l yap\u0131land\u0131r\u0131lmas\u0131 gerekti\u011fini g\u00f6steriyor. E\u011fer AwsCustomResource'un kendisi direkt olarak Harici Kimlik (External ID) ve AwsCustomResource ikilisi, AWS \u00e7oklu hesap ortamlar\u0131nda bir\u00e7ok ger\u00e7ek d\u00fcnya g\u00fcvenlik ve otomasyon senaryosunu m\u00fcmk\u00fcn k\u0131lar. \u0130\u015fte bu kombinasyonun g\u00fcc\u00fcn\u00fc g\u00f6steren iki vaka analizi:<\/p>\n B\u00fcy\u00fck bir kurulu\u015fun birden fazla AWS hesab\u0131 kulland\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim. Bu hesaplar, geli\u015ftirme, test, \u00fcretim ve farkl\u0131 i\u015f birimlerine ait olabilir. G\u00fcvenlik ekibi, t\u00fcm bu hesaplarda belirli g\u00fcvenlik politikalar\u0131n\u0131n (\u00f6rne\u011fin, \u015fifreleme ayarlar\u0131, a\u011f yap\u0131land\u0131rmalar\u0131, denetim kurallar\u0131) tutarl\u0131 bir \u015fekilde uygulanmas\u0131n\u0131 istiyor. Ancak, g\u00fcvenlik politikalar\u0131n\u0131 her hesaba manuel olarak uygulamak zaman al\u0131c\u0131, hata e\u011filimli ve \u00f6l\u00e7eklenemez bir y\u00f6ntemdir.<\/p>\n Senaryo:<\/strong> Merkezi G\u00fcvenlik Hesab\u0131 (Source Account), di\u011fer t\u00fcm \u00dcretim Hesaplar\u0131na (Target Accounts) belirli bir IAM politikas\u0131 ekleyecek veya CloudWatch log grubu yap\u0131land\u0131rmalar\u0131n\u0131 g\u00fcncelleyecek. G\u00fcvenlik ekibi, bu operasyonun y\u00fcksek g\u00fcvenlik standartlar\u0131nda yap\u0131lmas\u0131n\u0131 ve \"Confused Deputy\" sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korunmas\u0131n\u0131 istiyor.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong><\/p>\n Bir SaaS \u015firketinin (\u00f6rne\u011fin, bir g\u00fcvenlik izleme arac\u0131 veya bir yedekleme hizmeti) sizin AWS hesab\u0131n\u0131zda kaynaklar olu\u015fturmas\u0131 veya mevcut kaynaklar\u0131 y\u00f6netmesi gerekti\u011fini d\u00fc\u015f\u00fcn\u00fcn. Bu t\u00fcr \u00fc\u00e7\u00fcnc\u00fc taraf entegrasyonlar\u0131, genellikle sizin AWS hesab\u0131n\u0131zda bir IAM rol\u00fcn\u00fc \u00fcstlenerek \u00e7al\u0131\u015f\u0131r.<\/p>\n Senaryo:<\/strong> Bir \u00fc\u00e7\u00fcnc\u00fc taraf SaaS uygulamas\u0131 (\u00d6rn: \"ThirdPartySaaS\" isimli bir platform), sizin AWS hesab\u0131n\u0131zdaki (Target Account) bir S3 kovas\u0131n\u0131 yedekleyecek veya CloudWatch metriklerini toplayacak. SaaS platformu, sizin hesab\u0131n\u0131zda bir IAM rol\u00fc \u00fcstlenecek ve bu rol\u00fcn sadece belirli S3 kovas\u0131na eri\u015fim izni olmas\u0131n\u0131 istiyorsunuz. En \u00f6nemlisi, SaaS'\u0131n bu rol\u00fc \u00fcstlenirken, sadece kendi i\u00e7 sistemlerinin tetikledi\u011fi yasal i\u015flemler i\u00e7in kullan\u0131ld\u0131\u011f\u0131ndan emin olmak istiyorsunuz.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong><\/p>\n Bu vaka analizleri, Harici Kimlik kullan\u0131m\u0131n\u0131n sadece teknik bir gereklilik olman\u0131n \u00f6tesinde, ger\u00e7ek d\u00fcnya g\u00fcvenlik zorluklar\u0131na nas\u0131l pratik ve etkili \u00e7\u00f6z\u00fcmler sundu\u011funu g\u00f6stermektedir. AwsCustomResource ile bu t\u00fcr senaryolar\u0131 otomatikle\u015ftirmek, g\u00fcvenli ve \u00f6l\u00e7eklenebilir bulut altyap\u0131lar\u0131 olu\u015fturman\u0131n anahtar\u0131d\u0131r.<\/p>\n Harici Kimlik (External ID) kullan\u0131m\u0131, \u00e7apraz hesap operasyonlar\u0131nda g\u00fcvenli\u011fi art\u0131rman\u0131n temel bir ad\u0131m\u0131d\u0131r. Ancak, bu mekanizmadan en iyi \u015fekilde faydalanmak ve genel g\u00fcvenlik duru\u015funuzu daha da g\u00fc\u00e7lendirmek i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar mevcuttur:<\/p>\n Bu ileri d\u00fczey g\u00fcvenlik ipu\u00e7lar\u0131 ve en iyi uygulamalar, Harici Kimlik kullan\u0131m\u0131n\u0131 tamamlar ve AWS ortam\u0131n\u0131z\u0131n genel g\u00fcvenlik duru\u015funu \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirir. G\u00fcvenlik, s\u00fcrekli bir s\u00fcre\u00e7tir ve bu prensipleri uygulayarak, \u00e7apraz hesap operasyonlar\u0131n\u0131z\u0131 daha sa\u011flam ve diren\u00e7li hale getirebilirsiniz.<\/p>\n AWS bulutunda \u00f6l\u00e7eklenebilir ve esnek mimariler tasarlarken, \u00e7oklu hesap stratejisi vazge\u00e7ilmez bir yap\u0131 ta\u015f\u0131d\u0131r. Bu strateji, kaynak izolasyonu, maliyet kontrol\u00fc ve y\u00f6netilebilirlik a\u00e7\u0131s\u0131ndan \u00f6nemli avantajlar sunarken, beraberinde hesaplar aras\u0131 operasyonlar\u0131n g\u00fcvenli\u011fiyle ilgili kritik zorluklar\u0131 da getirir. \u00d6zellikle AwsCustomResource gibi otomasyon ara\u00e7lar\u0131n\u0131 kullanarak farkl\u0131 hesaplarda kaynak y\u00f6netimi yaparken, g\u00fcvenlik risklerini minimize etmek hayati \u00f6nem ta\u015f\u0131r. Bu makale boyunca ele ald\u0131\u011f\u0131m\u0131z Harici Kimlik (External ID) mekanizmas\u0131, Confused Deputy sald\u0131r\u0131lar\u0131 gibi karma\u015f\u0131k g\u00fcvenlik tehditlerine kar\u015f\u0131 g\u00fc\u00e7l\u00fc bir savunma hatt\u0131 olu\u015fturur.<\/p>\n Harici Kimlik, rol \u00fcstlenme isteklerine ek bir kimlik do\u011frulama katman\u0131 ekleyerek, yetkili bir hizmetin k\u00f6t\u00fc niyetli bir akt\u00f6r taraf\u0131ndan manip\u00fcle edilmesini engeller. AwsCustomResource'lar arac\u0131l\u0131\u011f\u0131yla Harici Kimlik kullan\u0131m\u0131n\u0131 entegre etmek, CloudFormation veya CDK ile da\u011f\u0131t\u0131lan altyap\u0131n\u0131z\u0131n sadece i\u015flevsel de\u011fil, ayn\u0131 zamanda g\u00fcvenlik best practice'lerine uygun olmas\u0131n\u0131 sa\u011flar. Hedef hesapta rol\u00fcn Trust Policy'sine Unutulmamal\u0131d\u0131r ki, g\u00fcvenlik tek seferlik bir i\u015flem de\u011fil, s\u00fcrekli bir s\u00fcre\u00e7tir. External ID'leri benzersiz, rastgele tutmak, d\u00fczenli olarak d\u00f6nd\u00fcrmek, en az yetkilendirme prensibini uygulamak ve t\u00fcm rol \u00fcstlenme eylemlerini izlemek, g\u00fcvenli bir AWS ortam\u0131n\u0131n s\u00fcrd\u00fcr\u00fclmesi i\u00e7in kritik \u00f6neme sahiptir. AWS altyap\u0131n\u0131z\u0131 b\u00fcy\u00fct\u00fcrken ve otomasyon seviyenizi art\u0131r\u0131rken, g\u00fcvenlik her zaman \u00f6ncelikli olmal\u0131d\u0131r. Harici Kimlik deste\u011fi ile AwsCustomResource kullan\u0131m\u0131n\u0131 benimseyerek, hesaplar aras\u0131 operasyonlar\u0131n\u0131z\u0131n sa\u011flaml\u0131\u011f\u0131n\u0131 ve g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilir, b\u00f6ylece bulut yolculu\u011funuzda daha g\u00fcvende olabilirsiniz.<\/p>\n C: External ID, \u00f6zellikle otomatikle\u015ftirilmi\u015f sistemler, \u00fc\u00e7\u00fcnc\u00fc taraf hizmetler veya \u00e7apraz hesap otomasyonlar\u0131nda \"Confused Deputy\" sald\u0131r\u0131s\u0131n\u0131 \u00f6nlemek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu senaryolarda, bir hizmetin (veya ba\u015fka bir hesab\u0131n) ba\u015fka bir hesaptaki bir rol\u00fc \u00fcstlenmesi s\u00f6z konusudur. Kullan\u0131c\u0131lar ise genellikle MFA gibi farkl\u0131 kimlik do\u011frulama mekanizmalar\u0131 kullan\u0131r ve do\u011frudan etkile\u015fimde bulunurlar. External ID'nin temel amac\u0131, rol\u00fc \u00fcstlenen taraf\u0131n \"niyetini\" do\u011frulamakt\u0131r.<\/p>\n<\/li>\n C: IAM rol\u00fc bir kimliktir; belirli izinlere sahip ge\u00e7ici kimlik bilgileri sa\u011flar ve belirli eylemleri ger\u00e7ekle\u015ftirmesine izin verilir. External ID ise bu rol\u00fc \u00fcstlenme s\u00fcrecine eklenen bir g\u00fcvenlik ko\u015fuludur. Rol\u00fc \u00fcstlenme iste\u011fi yapan\u0131n, rol\u00fcn Trust Policy'sinde tan\u0131mlanan spesifik bir gizli de\u011feri sa\u011flamas\u0131n\u0131 zorunlu k\u0131lar. Rol, yetkiyi tan\u0131mlar; External ID, yetkiyi kimin \u00fcstlenebilece\u011fine ek bir g\u00fcvenlik katman\u0131 ekler.<\/p>\n<\/li>\n C: Sadece AWS hesab\u0131 kimli\u011fi veya IAM ARN'i Trust Policy'ye eklemek, Confused Deputy sald\u0131r\u0131lar\u0131na kar\u015f\u0131 yeterli koruma sa\u011flamaz. K\u00f6t\u00fc niyetli bir akt\u00f6r, yetkili bir servisi (\u00f6rne\u011fin, bir AwsCustomResource) manip\u00fcle ederek, sizin hesab\u0131n\u0131zdaki rol\u00fc \u00fcstlenmesini sa\u011flayabilir, \u00e7\u00fcnk\u00fc servisin yetkilendirilmi\u015f bir hesab\u0131n par\u00e7as\u0131d\u0131r. External ID, bu durumu \u00f6nler; \u00e7\u00fcnk\u00fc k\u00f6t\u00fc niyetli akt\u00f6r, External ID'yi bilmedi\u011fi i\u00e7in rol\u00fc \u00fcstlenme iste\u011fi ba\u015far\u0131s\u0131z olur.<\/p>\n<\/li>\n C: External ID'yi kodunuza hardcode etmek yerine, AWS Secrets Manager veya SSM Parameter Store gibi hizmetlerde saklay\u0131p, AwsCustomResource'un \u00e7al\u0131\u015ft\u0131\u011f\u0131 Lambda fonksiyonunun \u00e7al\u0131\u015fma zaman\u0131nda bu de\u011feri \u00e7ekmesini sa\u011flayabilirsiniz. Bu, g\u00fcvenlik ve y\u00f6netilebilirlik a\u00e7\u0131s\u0131ndan en iyi uygulamad\u0131r. Ayr\u0131ca, CDK veya CloudFormation'a parametre olarak ge\u00e7irmek de bir y\u00f6ntemdir, ancak Secrets Manager daha g\u00fcvenli rotasyon ve eri\u015fim kontrol\u00fc sa\u011flar.<\/p>\n<\/li>\n<\/ul>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"AWS bulutunda kaynak y\u00f6netimi yaparken hesaplar aras\u0131 operasyonlar ka\u00e7\u0131n\u0131lmaz hale gelir. Ancak bu esneklik, beraberinde ciddi g\u00fcvenlik riskleri…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1406],"tags":[],"class_list":{"0":"post-34643","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-aws","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nsts:ExternalId<\/code> ko\u015fulu eklenir. Bu ko\u015ful, rol\u00fc \u00fcstlenme iste\u011fi yapan\u0131n, rol\u00fcn Trust Policy’sinde belirtilen External ID de\u011feri ile e\u015fle\u015fen bir External ID sa\u011flamas\u0131n\u0131 zorunlu k\u0131lar.<\/p>\nAwsCustomResource ile Harici Kimlik Kullan\u0131m\u0131n\u0131 Nas\u0131l Entegre Ederiz?<\/h2>\n
Hedef Hesapta Rol Tan\u0131mlamas\u0131: Trust Policy’ye External ID Ekleme<\/h3>\n
sts:ExternalId<\/code> ko\u015fulu i\u00e7ermelidir. \u0130\u015fte bir AWS CDK \u00f6rne\u011fi:<\/p>\n\nimport * as iam from 'aws-cdk-lib\/aws-iam';\nimport { Stack, StackProps } from 'aws-cdk-lib';\nimport { Construct } from 'constructs';\n\nexport class TargetAccountStack extends Stack {\n constructor(scope: Construct, id: string, props?: StackProps) {\n super(scope, id, props);\n\n \/\/ Bu, Kaynak Hesap'\u0131n AWS Hesap Kimli\u011fi olmal\u0131\n const sourceAccountArn = arn:aws:iam::${props?.env?.account}:root<\/code>; \n const externalId = 'MySecureAndUniqueExternalId123'; \/\/ G\u00fcvenli, rastgele bir External ID\n\n \/\/ AwsCustomResource'un \u00fcstlenece\u011fi IAM Rol\u00fc\n const crossAccountRole = new iam.Role(this, 'CrossAccountAccessRole', {\n assumedBy: new iam.FederatedPrincipal(\n 'arn:aws:iam::aws:policy\/service-role\/AWSLambdaBasicExecutionRole', \/\/ Bu, temsili, as\u0131l ARN a\u015fa\u011f\u0131daki gibi olmal\u0131\n {\n StringEquals: {\n 'sts:ExternalId': externalId,\n },\n 'aws:SourceAccount': props?.env?.account, \/\/ Sadece belirli bir hesaptan geliyorsa\n },\n 'sts:AssumeRole'\n ),\n \/\/ Ger\u00e7ekte, assumedBy \u015funa benzer olmal\u0131:\n \/\/ assumedBy: new iam.AccountPrincipal(sourceAccountAccountID).withConditions({\n \/\/ StringEquals: {\n \/\/ 'sts:ExternalId': externalId,\n \/\/ },\n \/\/ }),\n \/\/ veya daha geneli:\n assumedBy: new iam.AnyPrincipal().withConditions({\n StringEquals: {\n 'sts:ExternalId': externalId,\n },\n \/\/ Daha g\u00fcvenli hale getirmek i\u00e7in iste\u011fi yapan arn'i de k\u0131s\u0131tlayabiliriz\n 'aws:PrincipalArn': sourceAccountArn, \n }),\n description: 'Role for cross-account access from AwsCustomResource with External ID',\n });\n\n \/\/ Bu role, Hedef Hesapta yapmas\u0131 gereken izinleri ekleyin\n \/\/ \u00d6rne\u011fin, S3 kovas\u0131na eri\u015fim izni\n crossAccountRole.addToPolicy(new iam.PolicyStatement({\n actions: ['s3:GetObject', 's3:PutObject'],\n resources: ['arn:aws:s3:::my-target-bucket\/*', 'arn:aws:s3:::my-target-bucket'],\n }));\n\n \/\/ CDK \u00e7\u0131kt\u0131s\u0131 olarak rol ARN'ini kullan\u0131\u015fl\u0131 hale getirebiliriz\n \/\/ new CfnOutput(this, 'CrossAccountRoleArn', {\n \/\/ value: crossAccountRole.roleArn,\n \/\/ });\n }\n}\n<\/pre>\n\n
sourceAccountArn<\/code>: Kaynak hesab\u0131n ARN'i, bu sayede sadece bu hesab\u0131n rol\u00fc \u00fcstlenmesine izin verilir.<\/li>\nexternalId<\/code>: Belirledi\u011fimiz Harici Kimlik. Bu de\u011fer hem Hedef Hesap'taki rol\u00fcn Trust Policy'sinde hem de Kaynak Hesap'taki AwsCustomResource'da ayn\u0131 olmal\u0131d\u0131r.<\/li>\nassumedBy<\/code>: Bu k\u0131s\u0131m, rol\u00fc \u00fcstlenmeye yetkili prensibi tan\u0131mlar. AnyPrincipal<\/code> kullanarak herhangi bir prensibin (ancak sadece belirtilen External ID ve SourceAccount ile) rol\u00fc \u00fcstlenmesine izin veriyoruz. Daha spesifik olarak new iam.AccountPrincipal(sourceAccountAccountID)<\/code> de kullanabilirsiniz.<\/li>\nStringEquals<\/code> ko\u015fulu: sts:ExternalId<\/code> anahtar\u0131n\u0131 kullanarak, rol\u00fc \u00fcstlenmek isteyenin bizim belirledi\u011fimiz externalId<\/code> de\u011ferini sa\u011flamas\u0131n\u0131 zorunlu k\u0131l\u0131yoruz.<\/li>\naws:PrincipalArn<\/code> ko\u015fulu: Ek bir g\u00fcvenlik katman\u0131 olarak, iste\u011fi yapan\u0131n belirli bir ARN'e sahip olmas\u0131n\u0131 da \u015fart ko\u015fabiliriz.<\/li>\n<\/ul>\nKaynak Hesapta AwsCustomResource Konfig\u00fcrasyonu: External ID'yi Dinamik Olarak Kullanma<\/h3>\n
sts.assumeRole<\/code> API'sini kullanmal\u0131 ve bu \u00e7a\u011fr\u0131ya ExternalId<\/code> parametresini dahil etmelidir.<\/p>\n\nimport * as cdk from 'aws-cdk-lib';\nimport * as custom_resources from 'aws-cdk-lib\/custom-resources';\nimport * as iam from 'aws-cdk-lib\/aws-iam';\nimport { Construct } from 'constructs';\n\nexport class SourceAccountStack extends cdk.Stack {\n constructor(scope: Construct, id: string, props?: cdk.StackProps) {\n super(scope, id, props);\n\n const targetAccountRoleArn = 'arn:aws:iam::123456789012:role\/CrossAccountAccessRole'; \/\/ Hedef Hesap'taki rol\u00fcn ARN'i\n const externalId = 'MySecureAndUniqueExternalId123'; \/\/ Hedef Hesap'taki ile ayn\u0131 External ID\n\n \/\/ AwsCustomResource'un \u00e7al\u0131\u015faca\u011f\u0131 Lambda'n\u0131n \u00fcstlenece\u011fi rol\n const customResourceLambdaRole = new iam.Role(this, 'CustomResourceLambdaRole', {\n assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),\n description: 'Role for AwsCustomResource Lambda to assume cross-account role',\n });\n\n \/\/ CustomResourceLambdaRole'a, Hedef Hesap'taki rol\u00fc \u00fcstlenme izni verilmeli\n customResourceLambdaRole.addToPolicy(new iam.PolicyStatement({\n actions: ['sts:AssumeRole'],\n resources: [targetAccountRoleArn],\n }));\n \n \/\/ AWS Custom Resource'u tan\u0131mla\n new custom_resources.AwsCustomResource(this, 'MyCrossAccountCustomResource', {\n onCreate: {\n service: 'STS',\n action: 'assumeRole',\n parameters: {\n RoleArn: targetAccountRoleArn,\n RoleSessionName: 'CustomResourceSession',\n ExternalId: externalId, \/\/ BURASI KR\u0130T\u0130K: External ID'yi burada sa\u011fl\u0131yoruz\n },\n \/\/ Bu \u00e7a\u011fr\u0131n\u0131n sonucunu CloudFormation'a d\u00f6nd\u00fcrme\n physicalResourceId: custom_resources.PhysicalResourceId.of('MyCrossAccountResourceID'),\n },\n \/\/ Opsiyonel: Di\u011fer API \u00e7a\u011fr\u0131lar\u0131n\u0131 hedef hesaptaki yeni rol ile yapma\n onUpdate: {\n service: 'S3',\n action: 'putObject', \/\/ \u00d6rnek bir S3 i\u015flemi\n parameters: {\n Bucket: 'my-target-bucket', \/\/ Hedef hesaptaki kova\n Key: 'custom-resource-output.txt',\n Body: 'Hello from custom resource!',\n },\n \/\/ \u00c7a\u011fr\u0131y\u0131 yapacak rol\u00fc belirtiyoruz: targetAccountRoleArn\n \/\/ Bu, assumeRole \u00e7a\u011fr\u0131s\u0131ndan d\u00f6nen ge\u00e7ici kimlik bilgilerini kullanacakt\u0131r\n \/\/ Ancak do\u011frudan AwsCustomResource'da bu karma\u015f\u0131k. Genellikle bu tip i\u015flemleri\n \/\/ ayr\u0131 bir Lambda'da yapmak ve o Lambda'n\u0131n assumeRole yapmas\u0131 daha yayg\u0131nd\u0131r.\n \/\/ AwsCustomResource do\u011frudan assumeRole yap\u0131p ard\u0131ndan farkl\u0131 bir API \u00e7a\u011f\u0131ramaz\n \/\/ ayn\u0131 custom resource tan\u0131m\u0131 i\u00e7inde.\n \/\/ Bu y\u00fczden, onUpdate veya onCreate i\u00e7inde assumeRole yap\u0131yorsan\u0131z,\n \/\/ di\u011fer t\u00fcm i\u015flemler ayr\u0131 bir Lambda fonksiyonu i\u00e7inde yap\u0131lmal\u0131 ve\n \/\/ assumeRole'dan d\u00f6nen kimlik bilgileri o Lambda'ya aktar\u0131lmal\u0131d\u0131r.\n \/\/ Ancak bu \u00f6rnekte basitle\u015ftirme amac\u0131yla assumeRole'un kendisi bir i\u015flem olarak g\u00f6sterildi.\n \/\/ Daha ger\u00e7ek\u00e7i senaryo i\u00e7in a\u015fa\u011f\u0131ya bak\u0131n.\n },\n \/\/ E\u011fer CustomResource'un Lambda's\u0131 ba\u015fka bir rol \u00fcstlenecekse,\n \/\/ o rol\u00fcn yetkilerini burada tan\u0131mlamal\u0131s\u0131n\u0131z.\n policy: custom_resources.AwsCustomResourcePolicy.fromSdkCalls({\n resources: custom_resources.AwsCustomResourcePolicy.ANY_RESOURCE, \/\/ \u0130lgili kaynaklar\u0131 daha spesifik yap\u0131n\n }),\n \/\/ CustomResource'un \u00e7al\u0131\u015faca\u011f\u0131 Lambda fonksiyonunun rol\u00fcn\u00fc belirtiyoruz\n role: customResourceLambdaRole,\n });\n\n \/\/ Ger\u00e7ek\u00e7i bir cross-account operasyon senaryosu:\n \/\/ AwsCustomResource, Hedef Hesap'taki bir SSM parametresini g\u00fcncellemek i\u00e7in kullan\u0131l\u0131yor.\n \/\/ Bu i\u015flem i\u00e7in Hedef Hesap'taki rol\u00fc \u00fcstlenmesi gerekiyor.\n new custom_resources.AwsCustomResource(this, 'UpdateTargetAccountSsmParameter', {\n onCreate: {\n service: 'SSM',\n action: 'putParameter',\n parameters: {\n Name: '\/my-app\/config\/value',\n Value: 'Updated from Source Account',\n Type: 'String',\n Overwrite: true,\n },\n physicalResourceId: custom_resources.PhysicalResourceId.of('SsmParameterUpdate'),\n \/\/ \u0130\u015eTE BURADA, bu API \u00e7a\u011fr\u0131s\u0131n\u0131 yaparken \u00fcstlenece\u011fi rol\u00fc belirtiyoruz.\n \/\/ Bu rol, yukar\u0131da Hedef Hesap'ta tan\u0131mlad\u0131\u011f\u0131m\u0131z ve External ID gerektiren rol olmal\u0131.\n \/\/ AwsCustomResource'un SDK \u00e7a\u011fr\u0131lar\u0131nda assumeRole<\/code> ile bir rol \u00fcstlenip\n \/\/ o rol ile i\u015flem yapmas\u0131 i\u00e7in, output<\/code> parametresini kullan\u0131p\n \/\/ assumeRole<\/code>'dan d\u00f6nen kimlik bilgilerini almak ve\n \/\/ sonraki \u00e7a\u011fr\u0131da bu kimlik bilgilerini kullanmak gerekir.\n \/\/ Ancak AwsCustomResource, tek bir \u00e7a\u011fr\u0131 i\u00e7inde bunu do\u011frudan desteklemez.\n \/\/ En do\u011fru y\u00f6ntem, customResourceLambdaRole'un hedef rol\u00fc \u00fcstlenmesine izin verip,\n \/\/ AwsCustomResource i\u00e7inde bir lambda fonksiyonu \u00e7a\u011f\u0131r\u0131p, bu lambda fonksiyonunun\n \/\/ sts.assumeRole yap\u0131p ard\u0131ndan hedef API \u00e7a\u011fr\u0131s\u0131n\u0131 yapmas\u0131d\u0131r.\n \/\/ Kod \u00f6rne\u011fini basitle\u015ftirmek ad\u0131na, AwsCustomResource'un execution rol\u00fcne\n \/\/ hedef rol\u00fc \u00fcstlenme yetkisi verip, AwsCustomResource'un do\u011frudan\n \/\/ Hedef Hesap'ta bir i\u015flem yapt\u0131\u011f\u0131n\u0131 varsay\u0131yoruz. Bu, CloudFormation'\u0131n\n \/\/ arka planda gerekli yetkilendirme ak\u0131\u015f\u0131n\u0131 y\u00f6netti\u011fi anlam\u0131na gelir.\n \/\/ Ancak, bu yakla\u015f\u0131m, hedef hesaptaki kaynaklara eri\u015fmek i\u00e7in\n \/\/ AwsCustomResource'un execution rol\u00fcne (customResourceLambdaRole)\n \/\/ direkt olarak yetki vermek anlam\u0131na gelir ki bu, External ID'nin amac\u0131na ayk\u0131r\u0131d\u0131r.\n \/\/ DO\u011eRU Y\u00d6NTEM, AwsCustomResource'un bir Lambda'y\u0131 tetiklemesi ve bu Lambda'n\u0131n\n \/\/ sts.AssumeRole ile hedef rol\u00fc \u00fcstlenerek (External ID sa\u011flayarak) i\u015flemi yapmas\u0131d\u0131r.\n \/\/ Bu \u00f6rne\u011fi basitle\u015ftirmek ad\u0131na, AwsCustomResource'un kendi Execution Rol\u00fc'n\u00fcn\n \/\/ Hedef Hesap'taki rol\u00fc \u00fcstlenip S3 i\u015flemine yetkilendirildi\u011fini varsayal\u0131m.\n \/\/ Bu durumda, \"TargetAccountRoleArn\" de\u011ferini policy<\/code> k\u0131sm\u0131nda kullanaca\u011f\u0131z.\n },\n \/\/ Bu custom resource'un kendi y\u00fcr\u00fctme rol\u00fc (customResourceLambdaRole)\n \/\/ Hedef Hesap'taki targetAccountRoleArn<\/code> rol\u00fcn\u00fc \u00fcstlenmeye yetkili olmal\u0131.\n policy: custom_resources.AwsCustomResourcePolicy.fromStatements([\n new iam.PolicyStatement({\n actions: ['sts:AssumeRole'],\n resources: [targetAccountRoleArn],\n }),\n new iam.PolicyStatement({\n actions: ['ssm:PutParameter'],\n resources: [arn:aws:ssm:${this.region}:${cdk.Stack.of(this).account}:parameter\/my-app\/config\/value<\/code>],\n \/\/ Ger\u00e7ekte bu kaynak, Hedef Hesap'ta olmal\u0131\n \/\/ resources: [arn:aws:ssm:${this.region}:${targetAccountId}:parameter\/my-app\/config\/value<\/code>],\n }),\n ]),\n role: customResourceLambdaRole,\n });\n }\n}\n<\/pre>\nAwsCustomResource<\/code>'un onCreate<\/code> (veya onUpdate<\/code>, onDelete<\/code>) blo\u011funda direkt olarak bir STS assumeRole<\/code> \u00e7a\u011fr\u0131s\u0131 g\u00f6sterildi. Bu \u00e7a\u011fr\u0131ya ExternalId<\/code> parametresi eklenerek, Hedef Hesap'taki rol\u00fcn beklentisi kar\u015f\u0131lan\u0131yor.<\/p>\nassumeRole<\/code> yap\u0131p ard\u0131ndan o rol ile ba\u015fka bir API \u00e7a\u011fr\u0131s\u0131 yapmas\u0131 do\u011frudan kolay de\u011fildir. Genellikle, assumeRole<\/code> \u00e7a\u011fr\u0131s\u0131 ayr\u0131 bir Lambda fonksiyonu i\u00e7inde yap\u0131l\u0131r, d\u00f6nen ge\u00e7ici kimlik bilgileri al\u0131n\u0131r ve bu kimlik bilgileri kullan\u0131larak Hedef Hesap'taki di\u011fer API \u00e7a\u011fr\u0131lar\u0131 ger\u00e7ekle\u015ftirilir. Ya da AwsCustomResource'un y\u00fcr\u00fctme rol\u00fcne (customResourceLambdaRole<\/code>), Hedef Hesap'taki rol\u00fc \u00fcstlenme izni verilir ve AwsCustomResource, Hedef Hesap'taki bir i\u015flemi do\u011frudan \u00e7a\u011f\u0131rmaya \u00e7al\u0131\u015f\u0131r. Bu durumda, CloudFormation'\u0131n arka planda rol \u00fcstlenme s\u00fcrecini y\u00f6netti\u011fi varsay\u0131l\u0131r, ancak bu do\u011frudan External ID'yi SDK \u00e7a\u011fr\u0131s\u0131 olarak ge\u00e7irme \u00f6rne\u011fi de\u011fildir. Yukar\u0131daki \u00f6rne\u011fimizde policy<\/code> k\u0131sm\u0131nda sts:AssumeRole<\/code> iznini vermemiz ve onCreate<\/code> i\u00e7inde service: 'SSM', action: 'putParameter'<\/code> gibi bir i\u015flem yaparken, AwsCustomResource'un bu rol\u00fc \u00fcstlenip o yetkilerle i\u015flemi yapmas\u0131n\u0131 sa\u011flamam\u0131z gerekir. Bu durumda ExternalId<\/code>, AWS SDK \u00e7a\u011fr\u0131s\u0131 i\u00e7inde de\u011fil, rol \u00fcstlenirken arka planda CloudFormation taraf\u0131ndan sa\u011flanmal\u0131d\u0131r. Bu karma\u015f\u0131kl\u0131k nedeniyle, \u00e7o\u011fu durumda External ID kullan\u0131m\u0131, ya bir do\u011frudan sts.assumeRole<\/code> \u00e7a\u011fr\u0131s\u0131 yapan \u00f6zel bir Lambda<\/strong> i\u00e7inde ya da \u00fc\u00e7\u00fcnc\u00fc taraf bir hizmetin sizin hesab\u0131n\u0131zdaki bir rol\u00fc \u00fcstlenmesi<\/strong> senaryosunda daha belirgindir.<\/p>\nsts.assumeRole<\/code> \u00e7a\u011fr\u0131s\u0131n\u0131 yapman\u0131z ve d\u00f6nen kimlik bilgilerini kullanarak yeni bir AWS SDK istemcisi olu\u015fturman\u0131z gerekir. Bu da AwsCustomResource'un sa\u011flad\u0131\u011f\u0131 kolayl\u0131\u011f\u0131n d\u0131\u015f\u0131na \u00e7\u0131karak, daha geleneksel bir Custom Resource Lambda's\u0131 yazmay\u0131 gerektirir.<\/p>\nsts:AssumeRole<\/code> yap\u0131yorsa (\u00f6rnekteki gibi), ExternalId parametresini direkt olarak parameters<\/code> i\u00e7inde belirterek bunu sa\u011flayabilirsiniz.<\/p>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131: Harici Kimlik ile G\u00fcvenli Cross-Account \u0130\u015flemleri<\/h2>\n
Vaka Analizi 1: Merkezi G\u00fcvenlik Y\u00f6netimi i\u00e7in G\u00fcvenli Politika Da\u011f\u0131t\u0131m\u0131<\/h3>\n
\n
SecurityPolicyDeployerRole<\/code>) tan\u0131mlan\u0131r. Bu rol\u00fcn Trust Policy'si, Merkezi G\u00fcvenlik Hesab\u0131'n\u0131n AWS Hesap Kimli\u011fini (AccountPrincipal<\/code>) ve benzersiz, rastgele bir ExternalId<\/code> \u015fart\u0131n\u0131 i\u00e7erir. Bu rol, gerekli IAM (\u00f6rne\u011fin, iam:AttachRolePolicy<\/code>) veya CloudWatch (\u00f6rne\u011fin, logs:CreateLogGroup<\/code>, logs:PutRetentionPolicy<\/code>) izinlerine sahiptir.<\/li>\nSecurityPolicyDeployerRole<\/code> rol\u00fcn\u00fc \u00fcstlenirken, o hesaba \u00f6zel olarak belirlenmi\u015f ExternalId<\/code>'yi sa\u011flar.<\/li>\nsts:AssumeRole<\/code> \u00e7a\u011fr\u0131s\u0131n\u0131 yaparak ge\u00e7ici kimlik bilgileri al\u0131r ve ard\u0131ndan bu kimlik bilgileriyle Hedef Hesap'taki istenen API \u00e7a\u011fr\u0131lar\u0131n\u0131 (politika ekleme, log grubu g\u00fcncelleme vb.) ger\u00e7ekle\u015ftirir. External ID sayesinde, k\u00f6t\u00fc niyetli bir akt\u00f6r, Merkezi G\u00fcvenlik Hesab\u0131'ndaki Custom Resource'u manip\u00fcle etmeye \u00e7al\u0131\u015fsa bile, her hesaba \u00f6zel External ID'yi bilmedi\u011fi i\u00e7in rol\u00fc \u00fcstlenemez ve yetkisiz operasyonlar engellenir. Bu, g\u00fcvenlik politikalar\u0131n\u0131n merkezi ve g\u00fcvenli bir \u015fekilde da\u011f\u0131t\u0131lmas\u0131n\u0131 sa\u011flar, tutarl\u0131l\u0131\u011f\u0131 garanti eder ve operasyonel y\u00fck\u00fc azalt\u0131r.<\/li>\n<\/ol>\nVaka Analizi 2: \u00dc\u00e7\u00fcnc\u00fc Taraf Entegrasyonlar\u0131nda Minimum Yetkilendirme<\/h3>\n
\n
ThirdPartySaaSBackupRole<\/code>) olu\u015fturursunuz. Bu rol\u00fcn Trust Policy'si, ThirdPartySaaS'\u0131n AWS Hesap Kimli\u011fini (AccountPrincipal<\/code>) ve SaaS platformunun size sa\u011flad\u0131\u011f\u0131 benzersiz bir ExternalId<\/code>'yi i\u00e7erir. Bu External ID, yaln\u0131zca SaaS platformu taraf\u0131ndan bilinen ve size \u00f6zel bir de\u011ferdir. Role, yaln\u0131zca belirli S3 kovalar\u0131na (s3:GetObject<\/code>, s3:ListBucket<\/code>) veya CloudWatch metriklerine (cloudwatch:GetMetricData<\/code>) eri\u015fim gibi minimum gerekli izinler verilir.<\/li>\nThirdPartySaaSBackupRole<\/code>'\u00fcn ARN'sini belirtirsiniz. SaaS platformu, sizin hesab\u0131n\u0131zdaki rol\u00fc \u00fcstlenmek istedi\u011finde, bu ARN'yi ve External ID'yi kullanarak bir sts:AssumeRole<\/code> \u00e7a\u011fr\u0131s\u0131 yapar.<\/li>\n\u0130leri D\u00fczey G\u00fcvenlik \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
\n
arn:aws:s3:::my-bucket\/*<\/code> yerine sadece belirli bir objeyi belirtin).<\/li>\nsts:ExternalId<\/code>'ye ek olarak, IAM Trust Policy'lerinde di\u011fer ko\u015ful anahtarlar\u0131n\u0131 da kullanarak g\u00fcvenli\u011fi art\u0131rabilirsiniz. \u00d6rne\u011fin:\n\n
aws:SourceIp<\/code>: Rol \u00fcstlenme iste\u011finin belirli IP aral\u0131klar\u0131ndan gelmesini zorunlu k\u0131lmak.<\/li>\naws:SourceVpc<\/code> veya aws:SourceVpce<\/code>: \u0130ste\u011fin belirli bir VPC veya VPC Endpoint'ten gelmesini sa\u011flamak.<\/li>\naws:MultiFactorAuthPresent<\/code>: MFA (\u00c7ok Fakt\u00f6rl\u00fc Kimlik Do\u011frulama) gereklili\u011fi.<\/li>\naws:PrincipalArn<\/code>: Rol\u00fc \u00fcstlenecek prensibin tam ARN'sini belirterek daha dar bir yetkilendirme sa\u011flamak.<\/li>\n<\/ul>\n<\/li>\nsts:AssumeRole<\/code> \u00e7a\u011fr\u0131lar\u0131n\u0131 izleyin. Bu g\u00fcnl\u00fckler, kimin ne zaman hangi rol\u00fc \u00fcstlendi\u011fini ve External ID'nin sa\u011flan\u0131p sa\u011flanmad\u0131\u011f\u0131n\u0131 g\u00f6sterir. Anormal rol \u00fcstlenme giri\u015fimlerini veya ba\u015far\u0131s\u0131z denemeleri tespit etmek i\u00e7in CloudWatch metrikleri ve alarmlar\u0131 yap\u0131land\u0131r\u0131n. AWS Security Hub ve GuardDuty gibi servisler de g\u00fcvenlik olaylar\u0131n\u0131 otomatik olarak alg\u0131lamaya yard\u0131mc\u0131 olabilir.<\/li>\nSonu\u00e7: Hesaplar Aras\u0131 Operasyonlarda G\u00fcvenli\u011fin \u00d6nemi<\/h2>\n
sts:ExternalId<\/code> ko\u015fulu eklemek ve kaynak hesaptaki AwsCustomResource'un bu External ID'yi do\u011fru bir \u015fekilde sa\u011flamas\u0131n\u0131 yap\u0131land\u0131rmak, bu s\u00fcrecin ana ad\u0131mlar\u0131d\u0131r. Ger\u00e7ek d\u00fcnya senaryolar\u0131, merkezi g\u00fcvenlik y\u00f6netimi ve \u00fc\u00e7\u00fcnc\u00fc taraf entegrasyonlar\u0131nda Harici Kimli\u011fin nas\u0131l etkin bir \u015fekilde kullan\u0131labilece\u011fini g\u00f6stermi\u015ftir.<\/p>\nS\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n