AWS Organizations’ta IAM Rolleri İçin İzin Sınırları Kullanımı

AWS Organizations yönetim hesabında IAM rolü oluştururken güvenlik ve kontrolü nasıl artırırsınız? İzin Sınırları (Permission Boundaries), delegasyon modelinizi güçlendirerek yetki karmaşasını ortadan kaldırır ve güvenlik duruşunuzu sağlamlaştırır. Bu makale, özellikle büyük ve karmaşık bulut ortamlarında, yetki yönetiminin delegasyonunu güvenli bir şekilde nasıl yapacağınızı adım adım açıklayacaktır.

Modern bulut altyapıları, özellikle AWS gibi dinamik ve ölçeklenebilir platformlar, işletmelere büyük esneklik sunar. Ancak bu esneklik, beraberinde karmaşık güvenlik yönetimi zorluklarını da getirir. Büyük şirketler ve kurumsal yapılar genellikle çok sayıda AWS hesabına, ekibine ve projesine sahip olur. Bu durum, merkezi bir yönetim ekibinin tüm bu hesaplardaki IAM (Kimlik ve Erişim Yönetimi) rollerini ve politikalarını doğrudan yönetmesini son derece zorlaştırır.

Örneğin, bir geliştirme ekibinin kendi projeleri için belirli AWS kaynaklarına (örneğin EC2, S3, Lambda) ihtiyaç duyduğunu düşünelim. Yönetim ekibi, geliştiricilere ihtiyaç duydukları rolleri oluşturma yetkisi vermek isteyebilir; ancak bu yetkinin sınırlı ve kontrol edilebilir olmasını da arzu eder. Aksi takdirde, bir geliştirici istemeden veya bilerek çok geniş yetkilere sahip bir rol oluşturabilir ve bu da ciddi güvenlik açıklarına yol açabilir. İşte bu noktada delegasyon devreye girer. Delegasyon, belirli görev ve sorumlulukları daha alt seviyedeki ekiplere veya hesaplara devretme sürecidir. Ancak bu delegasyonun güvenli bir şekilde yapılması hayati önem taşır. Yanlış yapılandırılmış bir delegasyon modeli, “yetki tırmanması” (privilege escalation) riskini beraberinde getirir. Yani, başlangıçta sınırlı yetkili bir kullanıcı veya rol, kendine daha geniş yetkiler tanımlayabilme imkanına sahip olabilir. Bu, bulut güvenliğindeki en büyük endişelerden biridir.

AWS Organizations yönetim hesabında, tüm organizasyon için güvenlik ve maliyet yönetimi gibi merkezi fonksiyonlar bulunur. Bu hesap, genellikle en yüksek yetkilere sahip hesap olduğundan, burada yapılan her değişikliğin titizlikle denetlenmesi gerekir. Bu nedenle, alt hesaplara veya belirli ekiplere rol oluşturma yetkisi verirken, yönetim hesabının kendi güvenlik duruşunu tehlikeye atmadan bu işlemi gerçekleştirmesi zorunludur. Yönetim hesabındaki bir rol, yanlışlıkla veya kötü niyetli bir şekilde, tüm AWS Organizations yapısı üzerinde çok geniş yetkiler kazanabilir. Bu durum, organizasyonun genel güvenlik postürünü zayıflatır ve uyumluluk gereksinimlerini karşılamayı zorlaştırır. İşte bu tür senaryolarda, İzin Sınırları (Permission Boundaries) gibi gelişmiş IAM özellikleri devreye girerek, delegasyonun kontrol altında tutulmasını sağlar ve güvenlik açıklarının önüne geçer. Dolayısıyla, güvenli ve ölçeklenebilir bir bulut ortamı için, yetki delegasyonunu doğru araçlarla ve doğru stratejilerle yönetmek kritik öneme sahiptir.

Temel Kavramlar: AWS IAM Rolleri ve İzin Sınırları Nelerdir?

AWS bulut ortamlarında kimlik ve erişim yönetimi (IAM), kaynaklara kimin, ne zaman ve ne şekilde erişebileceğini belirleyen temel güvenlik hizmetidir. IAM’in iki ana bileşeni kullanıcılar ve rollerdir. Kullanıcılar genellikle bireysel kişilerle eşleşirken, roller uygulamalar, hizmetler veya geçici olarak yetki alması gereken kullanıcılar için tasarlanmıştır. Bu bölümde, IAM rollerini ve ardından İzin Sınırları kavramını detaylıca inceleyeceğiz.

IAM Rolleri Nasıl Çalışır ve Neden Önemlidir?

IAM rolleri, AWS’te geçici ve yetkilendirilmiş erişim sağlamanın en güvenli ve esnek yoludur. Bir rol, belirli bir AWS hesabı içindeki veya hesaplar arası güven ilişkisiyle başka bir hesaptaki kaynaklara erişmek için kullanılabilecek izinler kümesidir. Rollerin önemi, kullanıcı kimlik bilgileri (kullanıcı adı ve şifre) gerektirmemelerinden kaynaklanır. Bunun yerine, bir varlık (kullanıcı, uygulama veya AWS hizmeti) bir rolü üstlendiğinde, o rolün tanımladığı geçici güvenlik kimlik bilgilerini (geçici erişim anahtarı, gizli erişim anahtarı ve oturum belirteci) alır. Bu geçici kimlik bilgileri belirli bir süre sonra otomatik olarak sona erer, bu da uzun ömürlü ve çalınma riski taşıyan kimlik bilgilerine olan ihtiyacı ortadan kaldırır.

Rollerin temel avantajları şunlardır:

• Geçici Yetkilendirme: Uzun ömürlü kimlik bilgileri yönetimi ihtiyacını ortadan kaldırır.
• Hesaplar Arası Erişim: Farklı AWS hesapları arasında güvenli ve kontrollü kaynak erişimi sağlar.
• Hizmet Yetkilendirmesi: EC2, Lambda gibi AWS hizmetlerinin diğer AWS kaynaklarına güvenli bir şekilde erişmesini sağlar.
• Least Privilege (En Az Ayrıcalık) İlkesi: Yalnızca bir görevi yerine getirmek için gereken minimum izinleri vererek güvenlik riskini azaltır.

Örneğin, bir Lambda fonksiyonunun bir S3 bucket’ına yazması gerektiğinde, bu Lambda fonksiyonuna özel bir IAM rolü atanır ve bu rol yalnızca o S3 bucket’ına yazma izni verir. Bu, Lambda fonksiyonunun diğer hassas kaynaklara erişmesini engeller.

İzin Sınırları (Permission Boundaries) Nedir ve Nasıl Fark Yaratır?

İzin Sınırları (Permission Boundaries), AWS IAM’de bir kimliğin (kullanıcı veya rol) sahip olabileceği maksimum izinleri belirlemek için kullanılan gelişmiş bir özelliktir. Kendi başına bir izin verme mekanizması değildir; aksine, varlığa (kullanıcı veya rol) eklenmiş olan diğer tüm izin politikalarının izinlerini kısıtlayan bir “üst limit” görevi görür. Yani, bir kimliğe hem bir izin politikası hem de bir izin sınırı eklenmişse, kimliğin etkili izinleri, her iki politikada da açıkça izin verilen eylemlerin kesişimi olacaktır. Eğer bir eylem izin politikalarında izin verilmiş ancak izin sınırında açıkça reddedilmişse veya izin sınırında hiç bahsedilmemişse, o eylem gerçekleştirilemez.

Bu konsepti bir örnekle açıklayalım: Bir geliştiriciye “tüm EC2 işlemlerini yapabilir” izni veren bir politika atadığınızı düşünün. Ancak aynı geliştiriciye, “yalnızca belirli bir VPC içindeki EC2’leri yönetebilir” şeklinde bir izin sınırı atarsanız, geliştirici tüm EC2 işlemlerini yapma iznine sahip olsa bile, izin sınırı nedeniyle yalnızca belirli VPC içindeki kaynaklarda işlem yapabilecektir. Bu, özellikle yönetim hesaplarında veya yetki devri senaryolarında, alt ekiplerin kendilerine veya başkalarına gereğinden fazla yetki atamasını engellemek için inanılmaz derecede güçlü bir araçtır.

İzin Sınırları’nın temel faydaları şunlardır:

• Güvenli Yetki Delegasyonu: Yöneticilerin, belirli alt ekiplere veya hesaplara rol oluşturma veya politika ekleme yetkisi verirken, bu yetkinin kapsamını net bir şekilde sınırlamasını sağlar.
• “Privilege Escalation”ı Önleme: Bir kullanıcının veya rolün kendi izinlerini artırmasını (örneğin kendine yönetici yetkisi vermesini) engeller.
• Merkezi Güvenlik Politikası Uygulaması: Organizasyon genelinde güvenlik uyumluluk kurallarının tutarlı bir şekilde uygulanmasına yardımcı olur.
• Basitleştirilmiş Güvenlik Denetimi: Etkili izinleri analiz etmeyi kolaylaştırır, çünkü bir rolün ne yapabileceği hem rolün kendi politikaları hem de izin sınırı tarafından belirlenir.

Özetle, IAM rolleri belirli görevler için yetkilendirme sağlarken, İzin Sınırları bu yetkilendirmenin üst sınırını belirleyerek güvenliği daha da sıkılaştırır. Bu iki kavramın birleşimi, AWS ortamlarında sağlam ve ölçeklenebilir bir güvenlik duruşu oluşturmak için vazgeçilmezdir.

Neden AWS Organizations Yönetim Hesabında İzin Sınırları Kullanmalıyız?

AWS Organizations, birden fazla AWS hesabını merkezi olarak yönetmenizi sağlayan güçlü bir hizmettir. Organizasyon içindeki tüm hesaplar üzerinde politika yönetimi, faturalandırma birleştirme ve merkezi güvenlik kontrolleri gibi özellikler sunar. Yönetim hesabı, bu yapının merkezindedir ve en yüksek ayrıcalıklara sahip olma eğilimindedir. Bu durum, yönetim hesabında oluşturulan IAM rollerinin ve verilen yetkilerin özel bir dikkatle ele alınmasını gerektirir.

Yönetim Hesabındaki Hassasiyet ve Riskler

Yönetim hesabı (Master/Payer account), tüm organizasyonun kök hesabıdır. Bu hesapta herhangi bir güvenlik ihlali, tüm bağlı hesaplara yayılarak felaketle sonuçlanabilecek bir etki yaratabilir. Yönetim hesabındaki bir kullanıcı veya rolün aşırı geniş yetkilere sahip olması, aşağıdaki ciddi riskleri beraberinde getirir:

• Hesaplar Arası Yetki Tırmanması: Yönetim hesabındaki bir varlık, diğer bağlı hesaplardaki kaynaklara erişimi artırabilir, hatta kendilerine yönetici yetkileri atayabilir.
• Merkezi Politika İhlali: AWS Organizations’ın Service Control Policies (SCP’ler) gibi merkezi güvenlik politikalarını bypass etme potansiyeli.
• Yanlışlıkla Geniş Yetki Verme: Geliştiriciler veya operasyon ekipleri, kendi görevlerini yerine getirmek için rol oluşturma veya politika ekleme yetkisine ihtiyaç duyabilir. Ancak bu yetkiyi sınırsız vermek, istemeden veya bilmeden güvenlik açıklarına yol açan çok geniş rollerin oluşturulmasına neden olabilir.
• Uyumsuzluk Riski: Sıkı düzenleyici gereksinimleri olan sektörlerde (finans, sağlık vb.), yönetim hesabındaki yetkilerin tam kontrolü ve denetlenebilirliği hayati öneme sahiptir. İzin Sınırları olmadan bu kontrolü sağlamak çok daha zordur.

İzin Sınırlarının Sunduğu Çözümler ve Avantajlar

İşte bu riskleri minimize etmek ve yönetim hesabındaki güvenlik duruşunu güçlendirmek için İzin Sınırları kritik bir rol oynar. İzin Sınırları kullanarak, yönetim hesabında yetki devri yaparken bile kontrolü elinizde tutabilirsiniz. Bunun başlıca nedenleri ve avantajları şunlardır:

1. “Never Exceed” Prensibinin Uygulanması: İzin Sınırları, bir rolün veya kullanıcının hiçbir zaman aşamayacağı maksimum izin setini tanımlar. Bu sayede, alt ekiplere “rol oluşturma” yetkisi verdiğinizde dahi, oluşturacakları rollerin belirli bir izin kümesinin dışına çıkamayacağını garanti altına alırsınız. Örneğin, bir ekip sadece EC2 ve S3 kaynakları üzerinde işlem yapacak roller oluşturabilir; asla IAM veya Organizations üzerinde yetki atayamaz.
2. Güvenli Delegasyon Modeli: Bir merkezi güvenlik ekibi, İzin Sınırları tanımlayarak diğer ekiplerin kendi ihtiyaçlarına uygun IAM rolleri oluşturmasına izin verebilir. Bu, merkezi ekibin iş yükünü azaltırken, yerel ekiplere özerklik verir ve “hızlı hareket etme” kabiliyetini korur. Delegasyon, güvenli bir çerçevede gerçekleşir.
3. “Privilege Escalation”ın Önlenmesi: Bir IAM rolü oluşturma yetkisine sahip kötü niyetli bir kullanıcı veya uygulama, kendisi için geniş yetkilere sahip bir rol oluşturmaya çalışabilir. Ancak, yönetim hesabında İzin Sınırları uygulandığında, oluşturulacak yeni rollerin izinleri, atanmış İzin Sınırı tarafından otomatik olarak kısıtlanır. Bu, bir rolün veya kullanıcının, doğrudan veya dolaylı olarak, kendisine izin sınırının izin verdiğinden daha fazla yetki atamasını engeller.
4. Organizasyonel Uyum ve Standartlaştırma: Organizasyonunuz genelinde tutarlı güvenlik standartları ve en iyi uygulamaları zorunlu kılmak için İzin Sınırlarını kullanabilirsiniz. Örneğin, tüm yeni rollerin bir belirli etiketleme standardına uymasını veya hassas veri erişimi olan rollerin Multi-Factor Authentication (MFA) gerektirmesini zorunlu kılan İzin Sınırları oluşturulabilir.
5. Gelişmiş Denetlenebilirlik ve Uyumluluk: İzin Sınırları, bir rolün etkili izin setini daha şeffaf hale getirir. Bu, denetimler sırasında bir rolün neden belirli bir eylemi yapıp yapamadığını anlamayı kolaylaştırır. Uyumluluk denetçileri için, güvenlik politikalarının nasıl uygulandığını göstermek daha basittir.

Sonuç olarak, AWS Organizations yönetim hesabında İzin Sınırları kullanmak, delegasyonun faydalarından yararlanırken aynı zamanda en yüksek güvenlik seviyesini korumanızı sağlar. Bu, büyük ve karmaşık AWS ortamlarında güvenliğin temel direklerinden biridir ve “least privilege” ilkesini daha güçlü bir şekilde uygulamanıza olanak tanır.

Bir IAM İzin Sınırı Politikası Nasıl Oluşturulur ve Uygulanır?

İzin Sınırları’nın teorik faydalarını anladıktan sonra, şimdi pratik uygulamasına geçelim. Bir İzin Sınırı oluşturmak ve bunu IAM rollerine uygulamak, sanıldığı kadar karmaşık değildir ancak dikkatli bir planlama ve uygulama gerektirir. Bu bölümde, adım adım bir İzin Sınırı politikası oluşturma ve bunu yeni bir IAM rolüne nasıl atayacağınızı göstereceğiz.

Adım 1: İzin Sınırı Politikasını Tanımlama ve Oluşturma

İzin Sınırı, aslında standart bir IAM yönetilen (managed) politikasıdır. Bu politika, bir rolün veya kullanıcının üstlenebileceği maksimum izinleri içerir. Yani, bu politikada “izin verilen” eylemler, rolün üst sınırını oluşturur. Politikanızı tasarlarken, delegasyon yapmak istediğiniz ekiplerin ne tür AWS kaynakları üzerinde işlem yapmasına izin vermek istediğinizi çok net belirlemelisiniz. Örneğin, bir geliştirme ekibinin yalnızca EC2 ve S3 hizmetlerinde işlem yapabilen roller oluşturmasını istiyorsak, İzin Sınırı politikamız bu hizmetlerin dışındaki işlemleri otomatik olarak kısıtlamalıdır.

Aşağıda, bir geliştirme ekibinin IAM rolleri oluştururken yalnızca belirli hizmetleri kullanmasına izin veren basit bir İzin Sınırı politikası örneği bulunmaktadır. Bu politika, oluşturulan rollerin hiçbir zaman IAM, Organizations veya tam yönetici yetkisi (*:*) gibi hassas eylemleri içeren izinlere sahip olmamasını sağlar.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictSensitiveActions",
            "Effect": "Deny",
            "Action": [
                "iam:*",
                "organizations:*",
                "cloudtrail:DeleteTrail",
                "cloudtrail:StopLogging",
                "sns:Publish",
                "s3:DeleteBucketPolicy",
                "s3:PutBucketPolicy",
                "s3:PutBucketPublicAccessBlock",
                "s3:PutAccountPublicAccessBlock",
                "s3:PutBucketAcl",
                "s3:DeleteBucketAcl",
                "s3:PutBucketVersioning",
                "s3:DeleteBucketVersioning",
                "s3:PutBucketWebsite",
                "s3:DeleteBucketWebsite",
                "s3:PutObjectAcl",
                "s3:DeleteObjectAcl",
                "ec2:DeleteInternetGateway",
                "ec2:DeleteNetworkAcl",
                "ec2:DeleteRouteTable",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteVpc",
                "ec2:DetachInternetGateway",
                "kms:DeleteAlias",
                "kms:DisableKey",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:TagKeys": "false"
                }
            }
        },
        {
            "Sid": "AllowSafeActions",
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "s3:*",
                "lambda:*",
                "rds:*",
                "dynamodb:*",
                "sqs:*",
                "sns:*",
                "logs:*",
                "cloudwatch:*",
                "ssm:*",
                "secretsmanager:*",
                "kms:Describe*",
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:GenerateDataKey*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequireMFAForSensitiveActions",
            "Effect": "Deny",
            "Action": [
                "s3:DeleteObject",
                "s3:DeleteBucket"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
    

Bu politika, bazı hassas IAM ve Organizations eylemlerini açıkça yasaklamanın yanı sıra, genellikle geliştiricilerin ihtiyaç duyduğu hizmetlere (EC2, S3, Lambda vb.) genel erişim sağlar. Ayrıca, belirli kritik S3 silme işlemleri için MFA (Çok Faktörlü Kimlik Doğrulama) kullanımını zorunlu kılar, bu da ekstra bir güvenlik katmanı ekler. Politikanın Deny bölümündeki Condition ifadesi ("Condition": { "Null": { "aws:TagKeys": "false" } }), bu özel reddetme kuralının yalnızca belirtilen etiket anahtarı mevcut olmadığında uygulanacağını belirtir. Bu, daha karmaşık politika yönetimi senaryolarında faydalı olabilir, örneğin belirli etiketlere sahip kaynaklarda daha esnek davranılmasına izin verirken diğerlerinde katı kısıtlamalar uygulamak gibi.

Politikayı oluşturmak için AWS IAM konsoluna gidin, "Policies" bölümüne tıklayın ve "Create policy" düğmesine basın. JSON sekmesini seçin ve yukarıdaki JSON içeriğini yapıştırın. Politikaya anlamlı bir isim verin, örneğin DevTeamPermissionBoundary. Daha sonra politikayı kaydedin.

Adım 2: IAM Rolü Oluştururken İzin Sınırını Uygulama

İzin Sınırı politikasını oluşturduktan sonra, sıra onu yeni oluşturacağınız IAM rollerine atamaya gelir. Bu, bir rol oluşturma sürecinin bir parçasıdır ve konsol, CLI veya SDK aracılığıyla yapılabilir.

AWS Konsolu Üzerinden Uygulama:

1. IAM konsoluna gidin ve "Roles" bölümüne tıklayın.
2. "Create role" düğmesine basın.
3. Rolün güvenilir varlığını (trusted entity) seçin (örneğin, "AWS service" veya "Another AWS account").
4. İzinleri ekleme adımı sırasında, "Add permissions" veya "Attach permissions policies" bölümüne gelmeden önce sayfanın alt kısmında "Permissions boundary - optional" bölümünü göreceksiniz.
5. "Set permissions boundary" seçeneğini etkinleştirin ve arama çubuğunu kullanarak Adım 1'de oluşturduğunuz DevTeamPermissionBoundary politikasını seçin.
6. Daha sonra, bu role atamak istediğiniz diğer standart izin politikalarını seçin. Unutmayın, bu politikaların izinleri, İzin Sınırı tarafından belirlenen üst sınırı aşamayacaktır.
7. Rol adını belirleyin ve rolü oluşturma işlemini tamamlayın.

Bu adımları takip ederek, yeni oluşturulan her rol, hem kendi izin politikaları hem de atadığınız İzin Sınırı tarafından kısıtlanacaktır. Bu yöntem, yönetim hesabındaki IAM rolü oluşturma delegasyonunu güvenli bir şekilde yapmanızı sağlar.

AWS CLI Üzerinden Uygulama:

Eğer otomasyon ve Infrastructure as Code (IaC) yaklaşımlarını kullanıyorsanız, AWS CLI veya SDK'lar aracılığıyla İzin Sınırı atayabilirsiniz. İşte bir CLI örneği:

İlk olarak, güven ilişkisi politikanızı tanımlayın (örneğin, bir EC2 örneğinin bu rolü üstlenmesine izin vermek için):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
    

Bu içeriği trust-policy.json olarak kaydedin.

Şimdi, rolü oluşturun ve PermissionsBoundary parametresi ile izin sınırını belirtin:

aws iam create-role \
    --role-name MyLimitedEC2Role \
    --assume-role-policy-document file://trust-policy.json \
    --permissions-boundary arn:aws:iam::ACCOUNT_ID:policy/DevTeamPermissionBoundary \
    --description "A limited EC2 role with a permission boundary"
    

ACCOUNT_ID yerine kendi AWS hesap ID'nizi yazmayı unutmayın. Rol oluşturulduktan sonra, ona ek izin politikaları ekleyebilirsiniz:

aws iam attach-role-policy \
    --role-name MyLimitedEC2Role \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

aws iam attach-role-policy \
    --role-name MyLimitedEC2Role \
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
    

Bu adımlarla, MyLimitedEC2Role rolü, hem AmazonS3ReadOnlyAccess ve AmazonEC2ReadOnlyAccess politikalarının izinlerine sahip olacak hem de DevTeamPermissionBoundary politikasının belirlediği üst sınırın dışına çıkamayacaktır. Bu sayede, delegasyonun kontrolü her zaman yönetim hesabının elinde kalır.

Gerçek Dünya Senaryosu: Geliştirici Rolü Delegasyonu İçin İzin Sınırları

Birçok büyük organizasyonda, geliştirme ekiplerine kendi AWS kaynaklarını yönetme ve dağıtma yetkisi vermek yaygın bir uygulamadır. Bu, "hızlı hareket etme" ve "devops" kültürünü teşvik eder. Ancak, bu delegasyonun kontrolsüz yapılması büyük güvenlik riskleri taşır. İşte bu senaryoda İzin Sınırları'nın nasıl kurtarıcı bir rol oynadığını gösteren gerçekçi bir vaka analizi.

Problem: Kontrolsüz Geliştirici Yetkilendirmesi

Büyük bir e-ticaret şirketi olan "GlobalShop", AWS Organizations yapısını kullanmaktadır. Farklı ürün ekipleri için ayrılmış birçok AWS hesabı (örneğin, "Product A Dev", "Product B Dev") bulunmaktadır. Güvenlik ekibi, geliştiricilerin kendi hesapları içinde Lambda fonksiyonları, S3 bucket'ları ve EC2 örnekleri gibi kaynakları oluşturmalarına izin veren bir IAM rolü (DevOpsEngineerRole) sağlamıştır. Bu rol, geliştiricilere yeni IAM rolleri ve politikaları oluşturma yetkisi de dahil olmak üzere oldukça geniş yetkiler vermiştir. Ancak, bu durum bir dizi soruna yol açmıştır:

• İstemsiz Yetki Tırmanması: Bir geliştirici, test amacıyla veya bilgisizlikle, IAMFullAccess gibi çok geniş yetkilere sahip bir IAM politikası oluşturdu ve bunu bir Lambda fonksiyonuna atadı. Bu durum, Lambda fonksiyonunun (ve dolayısıyla geliştiricinin) amaçlanandan çok daha geniş bir AWS kontrolüne sahip olmasına neden oldu.
• Güvenlik Standartlarından Sapma: Farklı ekipler, farklı güvenlik anlayışlarıyla, organizasyonun belirlediği etiketleme standartlarına uymayan veya gereksiz yere genel erişim sağlayan S3 bucket'ları gibi kaynakları oluşturdu.
• Denetim Zorlukları: Güvenlik denetimleri sırasında, her bir rolün etkili izinlerini anlamak zorlaştı, çünkü rollerin izinleri oluşturulduğu zaman ve atanmış politikalarla değişiyordu.
• Merkezi Güvenlik Endişesi: Yönetim hesabı, bu kontrolsüzlüğün gelecekteki güvenlik ihlallerine davetiye çıkaracağından endişe duyuyordu.

Çözüm: "DeveloperScopedBoundary" İzin Sınırı Uygulaması

GlobalShop'un merkezi güvenlik ekibi, bu sorunları çözmek ve geliştiricilerin çevikliklerini korurken aynı zamanda güvenliği sıkılaştırmak için İzin Sınırları'nı kullanmaya karar verdi. Aşağıdaki adımları izlediler:

Adım 1: "DeveloperScopedBoundary" Politikasının Tanımlanması

Güvenlik ekibi, tüm geliştirici odaklı rollerin aşamayacağı bir "DeveloperScopedBoundary" adında bir yönetilen IAM politikası oluşturdu. Bu politika, geliştiricilerin kendi hesapları içinde yaygın olarak kullandıkları hizmetlere (EC2, S3, Lambda, RDS, DynamoDB, SQS, SNS, CloudWatch, CloudTrail Read-Only) tam erişim sağlıyordu. Ancak, IAM üzerinde politikalar oluşturma, kullanıcı/rol oluşturma veya Organizations servisindeki işlemleri (SCP'leri değiştirme, hesap silme vb.) kesinlikle yasaklıyordu.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCommonDevActions",
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "s3:*",
                "lambda:*",
                "rds:*",
                "dynamodb:*",
                "sqs:*",
                "sns:*",
                "logs:*",
                "cloudwatch:*",
                "cloudtrail:Describe*",
                "cloudtrail:Get*",
                "cloudtrail:LookupEvents",
                "sagemaker:*",
                "comprehend:*",
                "translate:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyIamAndOrgActions",
            "Effect": "Deny",
            "Action": [
                "iam:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenySensitiveS3ActionsWithoutMFA",
            "Effect": "Deny",
            "Action": [
                "s3:DeleteObject",
                "s3:DeleteBucket",
                "s3:PutBucketPolicy"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        },
        {
            "Sid": "ForceResourceTagging",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:RequestTag/Project": "true",
                    "aws:RequestTag/Owner": "true"
                },
                "ForAnyValue:StringLike": {
                    "iam:RequestTag/Project": [
                        "*"
                    ],
                    "iam:RequestTag/Owner": [
                        "*"
                    ]
                }
            }
        }
    ]
}
    

Bu politika özellikle IAM ve Organizations servislerine erişimi tamamen engelliyor. Ayrıca, S3 üzerinde kritik silme ve politika atama işlemlerini MFA olmadan yasaklıyor. ForceResourceTagging bölümü ise yeni oluşturulan kaynaklar için belirli etiketlerin zorunlu olmasını sağlıyor, bu da maliyet yönetimi ve denetlenebilirlik için kritik bir adımdır.

Adım 2: Geliştirici Rolüne İzin Sınırının Atanması

Güvenlik ekibi, mevcut DevOpsEngineerRole rolünü güncelledi ve yeni oluşturulacak tüm geliştirici rollerine (veya mevcut rollere bir denetim sonrası) DeveloperScopedBoundary politikasını İzin Sınırı olarak atadı. Bu, geliştiricilerin rol oluşturma yetkisine sahip olsalar bile, oluşturdukları herhangi bir rolün DeveloperScopedBoundary'nin izin verdiği sınırların dışına çıkamayacağı anlamına geliyordu.

Sonuçlar ve Faydaları

Bu uygulama sayesinde GlobalShop aşağıdaki önemli faydaları elde etti:

• Gelişmiş Güvenlik Durumu: Artık geliştiriciler, istemeden veya kasten olsun, kendilerine veya uygulamalarına kritik AWS hizmetlerinde (IAM, Organizations) geniş yetkiler veremiyorlardı. "Privilege escalation" riski önemli ölçüde azaldı.
• Merkezi Güvenlik Kontrolü: Güvenlik ekibi, tüm organizasyondaki geliştirme rollerinin uyması gereken temel güvenlik standartlarını merkezi olarak belirleyebildi ve uygulayabildi.
• Geliştirici Özerkliği: Geliştiriciler, hala kendi hesapları içinde ihtiyaç duydukları kaynakları hızlı bir şekilde oluşturabiliyor ve yönetebiliyorlardı, ancak belirlenen güvenlik sınırları içinde. Bu, inovasyonu yavaşlatmadan güvenliği artırdı.
• Kolaylaştırılmış Denetim: Bir rolün ne yapabileceğini anlamak artık çok daha basitti, çünkü rolün izinleri hem kendi politikaları hem de İzin Sınırı tarafından net bir şekilde tanımlanıyordu.
• Uyum Gerekliliklerinin Karşılanması: Şirketin uyumluluk standartlarına (örneğin GDPR, SOC 2) uygunluk sağlamak daha kolay hale geldi, çünkü yetki devri kontrollü bir mekanizma ile yapılıyordu.

Bu vaka analizi, İzin Sınırları'nın AWS Organizations ortamında güvenli ve ölçeklenebilir yetki delegasyonu sağlamak için ne kadar güçlü bir araç olduğunu açıkça göstermektedir. Geliştirici verimliliğini korurken güvenlik risklerini azaltmanın pratik bir yoludur.

İleri Düzey Kullanım: Programatik İzin Sınırları ve Otomasyon

Büyük AWS ortamlarında, IAM yönetimi genellikle el ile yapılan işlemlerden çok, otomasyon araçları ve Infrastructure as Code (IaC) yaklaşımlarıyla gerçekleştirilir. İzin Sınırları da bu otomasyon süreçlerine sorunsuz bir şekilde entegre edilebilir, böylece binlerce rolün tutarlı bir şekilde yönetilmesi ve güvenliğinin sağlanması mümkün olur. Bu bölümde, İzin Sınırları'nı programatik olarak nasıl yöneteceğinizi ve otomasyon stratejilerine nasıl entegre edeceğinizi inceleyeceğiz.

AWS CLI ve SDK'lar ile İzin Sınırları Yönetimi

AWS Komut Satırı Arabirimi (CLI) ve yazılım geliştirme kitleri (SDK'lar - Python için Boto3, JavaScript için AWS SDK gibi) İzin Sınırları'nı programatik olarak oluşturma, güncelleme ve silme imkanı sunar. Bu, özellikle sürekli entegrasyon/sürekli teslimat (CI/CD) işlem hatları içinde IAM rolü oluşturmayı otomatikleştiren ekipler için çok değerlidir.

İzin Sınırı Politikası Oluşturma

Daha önce gösterdiğimiz gibi, bir IAM yönetilen politikası oluşturmak için aws iam create-policy komutunu kullanabilirsiniz. Bu, İzin Sınırı olarak kullanılacak olan temel politikayı tanımlar.

# Policy.json dosyasını yukarıdaki "DeveloperScopedBoundary" politikası ile oluşturun.
aws iam create-policy \
    --policy-name DeveloperScopedBoundary \
    --policy-document file://DeveloperScopedBoundary.json \
    --description "Permission boundary for developer roles."
    

Rol Oluştururken İzin Sınırı Atama

Bir rol oluştururken İzin Sınırı atamak için create-role komutunda --permissions-boundary parametresini kullanırız. Bu, IaC şablonlarınızda (örneğin CloudFormation, Terraform) rol tanımlarınızı yaparken bu sınırları doğrudan uygulayabileceğiniz anlamına gelir.

# trust-policy.json dosyasını oluşturun (örneğin, bir EC2 servisi için)
# {
#     "Version": "2012-10-17",
#     "Statement": [
#         {
#             "Effect": "Allow",
#             "Principal": { "Service": "ec2.amazonaws.com" },
#             "Action": "sts:AssumeRole"
#         }
#     ]
# }
aws iam create-role \
    --role-name AutomatedDevRole \
    --assume-role-policy-document file://trust-policy.json \
    --permissions-boundary arn:aws:iam::ACCOUNT_ID:policy/DeveloperScopedBoundary \
    --description "Role for automated development processes with boundary."
    

Mevcut Bir Role İzin Sınırı Güncelleme

Mevcut bir role İzin Sınırı eklemek veya değiştirmek için put-role-permissions-boundary komutunu kullanabilirsiniz. Bu, organizasyonunuzdaki güvenlik politikaları değiştiğinde veya yeni sınırlar tanımlandığında mevcut rolleri hızlıca güncellemenizi sağlar.

aws iam put-role-permissions-boundary \
    --role-name ExistingDevRole \
    --permissions-boundary arn:aws:iam::ACCOUNT_ID:policy/NewDeveloperScopedBoundary
    

İzin Sınırı'nı bir rolden kaldırmak için ise delete-role-permissions-boundary komutunu kullanabilirsiniz. Ancak bu işlem, rolün izinlerini sınırsız hale getireceği için dikkatli yapılmalıdır.

IaC (Infrastructure as Code) ile Otomasyon

CloudFormation ve Terraform gibi IaC araçları, İzin Sınırları'nı AWS altyapınızın bir parçası olarak tanımlamanıza ve yönetmenize olanak tanır. Bu, IAM politikalarını ve rol atamalarını versiyon kontrolü altında tutarak değişiklikleri izlenebilir, tekrar edilebilir ve tutarlı hale getirir.

AWS CloudFormation ile İzin Sınırı Tanımlama

CloudFormation şablonunda bir IAM rolü tanımlarken, PermissionsBoundary özelliğini kullanarak bir İzin Sınırı ARN'si belirleyebilirsiniz:

Resources:
  MyAutomatedDevRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AutomatedDevRoleCFN
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - ec2.amazonaws.com
            Action:
              - sts:AssumeRole
      Description: "An automated dev role managed by CloudFormation with a permission boundary."
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
      PermissionsBoundary: !Sub "arn:aws:iam::${AWS::AccountId}:policy/DeveloperScopedBoundary"
    

Burada !Sub fonksiyonu, mevcut AWS hesabı ID'sini dinamik olarak eklemek için kullanılır. Bu, şablonun farklı AWS hesaplarında yeniden kullanılabilir olmasını sağlar.

Terraform ile İzin Sınırı Tanımlama

Terraform kullanıcıları da benzer şekilde aws_iam_role kaynağında permissions_boundary özelliğini kullanabilirler:

resource "aws_iam_policy" "developer_boundary" {
  name        = "DeveloperScopedBoundaryTerraform"
  description = "Permission boundary for developer roles managed by Terraform."

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid = "AllowCommonDevActions"
        Effect = "Allow"
        Action = [
            "ec2:*",
            "s3:*",
            "lambda:*",
            "rds:*",
            "dynamodb:*"
        ]
        Resource = "*"
      },
      {
        Sid = "DenyIamAndOrgActions"
        Effect = "Deny"
        Action = [
            "iam:*",
            "organizations:*"
        ]
        Resource = "*"
      }
    ]
  })
}

resource "aws_iam_role" "automated_dev_role" {
  name               = "AutomatedDevRoleTerraform"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      }
    ]
  })
  permissions_boundary = aws_iam_policy.developer_boundary.arn
  description          = "Automated dev role with a permission boundary managed by Terraform."
}

resource "aws_iam_role_policy_attachment" "s3_read_attach" {
  role       = aws_iam_role.automated_dev_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}
    

Bu Terraform kodu, hem İzin Sınırı politikasını (aws_iam_policy) hem de bu sınıra sahip rolü (aws_iam_role) tanımlar ve ona ek bir politika ekler. Bu sayede, güvenlik politikalarınız kod olarak yönetilebilir ve otomatik dağıtım süreçlerine entegre edilebilir.

Programatik İzin Sınırı yönetimi ve otomasyonu, özellikle büyük ölçekli ve dinamik AWS ortamlarında IAM güvenliğini artırmak için vazgeçilmezdir. Bu yaklaşımla, güvenlik standartlarınızın her yeni rol oluşturulduğunda otomatik olarak uygulanmasını sağlayabilir, insan hatasını azaltabilir ve genel güvenlik duruşunuzu sürekli olarak güçlendirebilirsiniz.

İzin Sınırları Kullanırken Dikkat Edilmesi Gerekenler ve En İyi Uygulamalar

İzin Sınırları, AWS IAM güvenliğini güçlendirmek için son derece güçlü bir araçtır, ancak etkili bir şekilde kullanılmadığında veya yanlış yapılandırıldığında karmaşıklığa yol açabilir veya beklenmedik erişim sorunlarına neden olabilir. İşte İzin Sınırları'nı kullanırken dikkat etmeniz gerekenler ve en iyi uygulamalar.

1. İzin Sınırları "İzin Vermez", Sadece "Sınırlar"

Bu, İzin Sınırları hakkındaki en önemli yanılgılardan biridir. İzin Sınırları, bir kimliğe kendi başına herhangi bir izin vermez. Rolün veya kullanıcının etkili izinleri, her zaman hem kimliğe bağlı politikalar (inline veya managed) hem de İzin Sınırı politikasında açıkça izin verilen eylemlerin kesişimi olacaktır. Eğer bir eylem, kimliğe bağlı politikalarda izin verilmiş ancak İzin Sınırı'nda reddedilmişse veya İzin Sınırı'nda hiç belirtilmemişse, o eylem gerçekleştirilemez. Bu nedenle, İzin Sınırı politikalarınızı tasarlarken "Allow" ifadelerinin bile aslında bir üst sınır belirlediğini unutmayın. Daima "least privilege" prensibini göz önünde bulundurarak hem rolün kendisine atadığınız politikaları hem de İzin Sınırı'nı tasarlayın.

2. Test Edin, Test Edin, Tekrar Test Edin!

İzin Sınırları, IAM izinlerini anlamayı karmaşıklaştırabilir. Bir İzin Sınırı uyguladıktan sonra, ilgili rolün veya kullanıcının gerçekten ihtiyaç duyduğu tüm görevleri yerine getirebildiğini ve bunun ötesinde hiçbir yetkiye sahip olmadığını doğrulamak için kapsamlı testler yapın. AWS IAM Policy Simulator, bu süreçte çok faydalı bir araçtır. Rolün ve İzin Sınırı politikasının birleşiminin etkili izinlerini görmenize olanak tanır.

3. İzin Sınırı Politikalarını En Az Ayrıcalık Prensibiyle Tasarlayın

İzin Sınırı politikalarınızı, atandığı rollerin ihtiyaç duyabileceği en geniş yetki kümesini kapsayacak şekilde değil, aksine en kısıtlı ama işlevsel yetki kümesini kapsayacak şekilde tasarlayın. Örneğin, tüm geliştirici rollerinin ihtiyaç duyabileceği hizmetleri (EC2, S3, Lambda) içeren bir sınır oluşturun, ancak IAM veya Organizations gibi hassas hizmetlere erişimi kesinlikle kısıtlayın. Bu, delegasyonun güvenliğini en üst düzeye çıkarır.

4. İzin Sınırları ve SCP'ler Arasındaki Farkı Anlayın

Hem İzin Sınırları hem de Service Control Policies (SCP'ler) maksimum izinleri belirlemek için kullanılabilir, ancak farklı seviyelerde çalışırlar:

• SCP'ler: AWS Organizations seviyesinde çalışır ve bir kuruluş birimi (OU) veya hesap için tüm varlıkların (kullanıcılar, roller) yapabileceği maksimum eylemleri sınırlar. SCP'ler, root kullanıcısı dahil olmak üzere tüm IAM varlıklarını etkiler ve varsayılan olarak "reddetme" (Deny) ilkesiyle çalışır (ancak "Allow" SCP'leri de yazılabilir). Bir SCP bir eylemi reddederse, hiçbir IAM politikası bu eyleme izin veremez.
• İzin Sınırları: IAM varlığı (kullanıcı veya rol) seviyesinde çalışır. Bir rolün veya kullanıcının sahip olabileceği maksimum izinleri sınırlar. İzin Sınırı bir eylemi reddederse, kimliğe bağlı politikalar o eyleme izin veremez.

Bu iki mekanizma birbirini tamamlar. SCP'ler geniş organizasyonel güvenliği sağlarken, İzin Sınırları daha granüler delegasyon kontrolü sunar. Her ikisini de kullanmak, katmanlı bir güvenlik yaklaşımı sağlar.

5. Otomasyon ve Sürüm Kontrolünü Kullanın

İzin Sınırı politikalarını ve rol atamalarını CloudFormation, Terraform gibi Infrastructure as Code (IaC) araçlarıyla yönetin. Bu, politikaların tutarlılığını sağlar, değişiklikleri izlenebilir hale getirir ve insan hatası riskini azaltır. Ayrıca, tüm politikalarınızı sürüm kontrol sistemlerinde (Git gibi) saklayın.

6. İzin Sınırlarını Düzenli Olarak Gözden Geçirin ve Güncelleyin

İş gereksinimleri ve AWS hizmetleri sürekli değişir. İzin Sınırı politikalarınızın hala geçerli olduğundan, gereksiz izinler içermediğinden ve yeni güvenlik tehditlerine karşı koruma sağladığından emin olmak için düzenli olarak gözden geçirin. Gerekirse, bunları işlevsellikten ödün vermeden sıkılaştırın.

7. Etiketleme Standartlarını Zorlayın

İzin Sınırları içinde, yeni oluşturulan kaynaklar için belirli etiketlerin (örneğin "Project", "Owner", "Environment") zorunlu olmasını sağlayan koşullar (aws:RequestTag) ekleyebilirsiniz. Bu, kaynak envanter yönetimi, maliyet tahsisi ve güvenlik denetimleri için çok değerli bilgiler sağlar.

Bu en iyi uygulamaları takip ederek, İzin Sınırları'nı AWS Organizations yönetim hesabında güvenliği artırmak, yetki delegasyonunu kontrol altında tutmak ve genel bulut güvenlik duruşunuzu güçlendirmek için etkili bir şekilde kullanabilirsiniz.

Sonuç: Güvenli ve Ölçeklenebilir Bir Bulut Ortamı İçin İzin Sınırları

AWS Organizations yönetim hesabında IAM rolü oluşturma süreci, kuruluşlar için hem esneklik hem de ciddi güvenlik riskleri barındırır. Güvenli yetki delegasyonu, büyük ve dinamik AWS ortamlarında karşılaşabileceğiniz en önemli zorluklardan biridir. İşte bu noktada, İzin Sınırları (Permission Boundaries), AWS ortamınızda güvenliği artırmak ve "en az ayrıcalık" (least privilege) ilkesini etkin bir şekilde uygulamak için vazgeçilmez bir araç olarak karşımıza çıkmaktadır.

Bu makalede, İzin Sınırları'nın ne olduğunu, IAM rolleriyle nasıl çalıştığını ve özellikle AWS Organizations yönetim hesabında neden bu kadar kritik olduğunu detaylıca ele aldık. Geliştirici rolü delegasyonu senaryosuyla gerçek dünya uygulamasını gösterdik ve İzin Sınırları'nın programatik olarak nasıl yönetilebileceğine dair ileri düzey bilgiler sunduk. Unutmayın ki İzin Sınırları, izin veren bir mekanizma değil, aksine bir rolün veya kullanıcının sahip olabileceği maksimum yetkiyi belirleyen bir "üst sınır"dır. Bu özelliği sayesinde, alt ekiplere veya otomatik süreçlere rol oluşturma yetkisi verirken bile, bu rollerin belirlenen güvenlik parametrelerinin dışına çıkmasını engelleyebilirsiniz.

İzin Sınırları'nı doğru şekilde yapılandırmak ve yönetmek, yetki tırmanması riskini azaltır, merkezi güvenlik standartlarının tutarlı bir şekilde uygulanmasını sağlar ve genel uyumluluk gereksinimlerini karşılamanıza yardımcı olur. Karmaşık bulut ortamlarında güvenlik stratejinizin temel taşlarından biri olmalı ve otomasyon, düzenli denetim ve en iyi uygulamalarla desteklenmelidir. Gelecekte, AWS altyapınız büyüdükçe ve geliştikçe, İzin Sınırları, güvenlik ve operasyonel verimlilik arasındaki dengeyi korumanızda size kritik bir avantaj sağlayacaktır. AWS kaynaklarınızın güvenliğini sağlamak için bu güçlü aracı keşfetmeye ve uygulamaya devam edin.