Geliştiricilerin Gerçek Erişim Kontrol Politikalarına (Sadece Teoride Değil) Neden İhtiyaç Duyduğu
Kod gönderiyorsanız, bakımını yapıyorsunuz demektir. pipelineYapıt kayıtlarını yönetmek veya bunlarla ilgili işlem yapmak için teoriden fazlasına ihtiyacınız var. Zayıf veya tanımlanmamış erişim kontrol politikaları, depo üzerinde oynama girişimlerine yol açar. CI/CD suistimal ve kimlik bilgisi sızıntılarıDevSecOps, gizli izin ayarlarıyla yetinmek yerine, gerçek bir uygulama gerektirir.
Kod depoları genelinde erişim kontrol politikalarını etkili bir şekilde yönetmek için, CI/CD pipelinesve yapıt kayıt defterleri gibi durumlarda, birçok ekip Xygeni gibi otomatik uygulama araçlarına güvenmektedir. Rolleri, izinleri ve politika uyumluluğunu sürekli olarak izleyerek, Xygeni izin kaymalarını, yetkisiz erişimi ve manuel geçersiz kılmaları önlemeye yardımcı olur ve zorunlu erişim kontrolü teorisini eyleme dönüştürür.
Erişim kontrolü, kaynak kodunuzu doğrudan kilitler, derlemelerinizi güvence altına alır ve üretim ortamınızı korur. pipelineGeliştiriciler kontrolleri atlarsa veya hizmet hesaplarına geniş yetkiler verilirse, güvenlik ihlallerine kapı açmış olursunuz. Bu nedenle, zorunlu erişim kontrolü, MAC erişim kontrolü ve diğer modelleri anlamak çok önemlidir.
Geliştiricilerin Bilmesi Gereken Erişim Kontrol Politikası Türleri
Erişim kontrol politikaları üç ana kategoriye ayrılır ve her birinin kullanım alanı farklıdır. CI/CD İş akışları. İşte açıklığa kavuşturmak için hızlı bir yan yana karşılaştırma:
| Model | Erişimi Kim Kontrol Ediyor? | Tipik Kullanım Alanları CI/CD | Risk seviyesi |
|---|---|---|---|
| DAC (İsteğe Bağlı Erişim Kontrolü) | Kaynak sahibi (geliştirici, yönetici) | Depo veya kayıt defteri erişiminin manuel olarak paylaşılması | Yüksek (insan hatası) |
| RBAC (Rol Tabanlı Erişim Kontrolü) | Sistem, izinleri role göre atar. | GitHub dal koruması, kullanıcı rollerine dayalı CI iş erişimi | Orta (yanlış yapılandırılmış roller) |
| MAC (Zorunlu Erişim Kontrolü) | Sistem politikası tarafından uygulanır | Kimlerin dosya yayınlayabileceğini veya kod dağıtabileceğini belirler. | Düşük (politika, kullanıcı niyetini geçersiz kılar) |
MAC ve RBAC Arasındaki Farkı Açıklamak CI/CD bağlam
Rol tabanlı erişim kontrolünü karıştırmak kolaydır (RBACÖzellikle zorunlu erişim kontrolü (MAC erişim kontrolü) ile birlikte CI/CD ortamlar. Sırasında CI/CD GitHub ve GitLab gibi platformlar, rolleri ve izinleri yönetmek için RBAC kullanır (örneğin, kimin birleştirme veya dağıtım yapabileceği), ancak bu temelde rol tabanlıdır, gerçek MAC erişim kontrolü değildir.
RBAC, izinleri rollere (geliştirici, bakımcı vb.) göre atamanıza olanak tanır, ancak bu izinler yine de kullanıcı tarafından kontrol edilir ve değiştirilebilir. Yanlış yapılandırmalar veya izinlerin aşırı artması yaygın risklerdir.
Zorunlu erişim kontrolü (MAC erişim kontrolü) ise bunun aksine sistem veya altyapı düzeyinde uygulanır. Yöneticiler de dahil olmak üzere kullanıcılar bunu geçersiz kılamaz. MAC erişim kontrolünü platforma yerleştirilmiş politikalar olarak düşünün: bulut sağlayıcılarındaki IAM politikaları (örneğin, AWS IAM, GCP IAM) veya SELinux veya AppArmor gibi işletim sistemi düzeyindeki uygulama araçları. Bu durumlarda, erişim yalnızca önceden tanımlanmış, atlatılamaz kurallar karşılandığında verilir.
In CI/CDBirçok araç, sıkı kapsamlı IAM rolleri veya kaynağa özgü izinler aracılığıyla MAC erişim kontrolü davranışını simüle eder, ancak bu tam anlamıyla zorunlu erişim kontrolü değildir. Gerçek zorunlu erişim kontrolü uygulaması, erişimin insan yapılandırmasıyla değil, değiştirilemez erişim kontrol politikalarıyla yönetildiği, uygulama katmanının altında, işletim sistemi, ağ veya bulut altyapısı düzeyinde kontroller gerektirir.
Rol Tabanlı Erişim Kontrolü (RBAC)
RBAC, izinleri "geliştirici", "bakımcı" veya "sürüm yöneticisi" gibi tanımlanmış rollere eşler. GitHub gibi araçlarda yönetimi basitleştirir. GitLabKullanıcıları tek tek yapılandırmak yerine, onlara bir rol atayın ve sistemin kuralları uygulamasını sağlayın.
Örnek: GitHub CODEOWNERS dosyası
# CODEOWNERS /docs/ @doc-team /scripts/ @devops-team /main.py @maintainers Bu, kritik dizinlerdeki değişiklikleri yalnızca atanmış rollerin onaylayabilmesini sağlar.
GitLab rol ayarları: Ayarlar > Üyeler bölümünde proje erişimini yapılandırın:
- Geliştirici: Özellik dallarına itme işlemi yapılabilir.
- bakıcı: Korumalı dallara birleştirme yapılabilir.
- Konuk: Sadece okuma erişimi.
GitHub Actions İş Akışı RBAC örneği:
yaml # .github/workflows/deploy.yml name: Deploy to Production on: push: branches: - main jobs: deploy: if: github.actor == 'release-manager' runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Deploy run: ./scripts/deploy.sh Zorunlu Erişim Kontrolü (MAC)
Zorunlu erişim denetimi (MAC erişim denetimi), kullanıcıların ve yöneticilerin geçersiz kılamayacağı katı, sistem düzeyinde kurallar uygular. MAC erişim denetimini kullanın. Kimlerin okuma, yazma veya kritik kaynakları kullanma yetkisine sahip olduğunu sıkı bir şekilde kontrol etmek.
Örnek: Google Yapıt Kayıt Politikası (Basitleştirilmiş YAML)
yaml bindings: - role: roles/artifactregistry.writer members: - serviceAccount:ci-deployer@project.iam.gserviceaccount.com Örnek: Amazon ECR Politikası (Basitleştirilmiş YAML)
yaml Version: "2008-10-17" Statement: - Effect: Deny Principal: "*" Action: ecr:PutImage Resource: arn:aws:ecr:region:account-id:repository/my-app Condition: StringNotEquals: aws:userid: ci-service-account Manuel Geçersiz Kılma Riskleri ve MAC'in Bunları Nasıl Önlediği
RBAC ile ilgili en büyük risklerden biri şudur: DAC modelleri Kasıtlı veya kaz accidental manuel geçersiz kılma potansiyeli mevcuttur. Örneğin, bir yönetici veya geliştirici, korumalı bir kayıt defterine doğrudan dosyalar yükleyebilir veya tanımlanmış erişim kontrol politikalarının dışında aşırı izinler verebilir. Bu eylemler güvenlik açıklarına yol açabilir veya uyumluluk boşluklarına neden olabilir.
Zorunlu erişim kontrolü (MAC erişim kontrolü), yöneticilerin bile atlayamayacağı sistem düzeyindeki politikaları uygulayarak bu tür geçersiz kılmaları önler. Erişim kontrolücisİyonlar, altyapıya yerleştirilmiş değişmez kurallarla yönetilir (bulut IAM politikaları veya işletim sistemi düzeyindeki güvenlik modülleri gibi). Bu şu anlama gelir:
- Mac erişim kontrol politikası izin vermiyorsa, bir yönetici manuel olarak kayıt defterine dosya yükleyemez.
- Kullanıcılar, tanımlanmış erişim kontrol politikalarının dışında ayrıcalıklarını yükseltemez veya izinleri değiştiremez.
- Otomatik CI/CD pipelineİşlemler, kendilerine atanmış izinler dahilinde sıkı bir şekilde yürütülür ve kapsam genişlemesinin önüne geçilir.
Manuel müdahaleleri ortadan kaldırarak, zorunlu erişim kontrolü, tek başına RBAC veya DAC'ye kıyasla daha güçlü ve güvenilir bir güvenlik duruşu sağlar.
2.4 Takdirî Erişim Kontrolü (DAC)
DAC, kaynak sahiplerinin izinleri manuel olarak atamasına olanak tanır. Esnektir ancak risklidir. Yanlış bir paylaşım, bir depoyu tehlikeye atabilir. DAC şu şekilde çalışır: "Sahibi sizsiniz, kimin erişebileceğine siz karar verirsiniz."
Örnek E-posta: Geliştirici, harici bir işbirlikçiyi davet eder ve ona depoya yazma erişimi verir. İşbirlikçi, güvenli olmayan kodu doğrudan depoya gönderir. dev dalı.
In CI/CDDAC, bir geliştiricinin tanımlanmış herhangi bir erişim kontrol politikası dışında, konsol aracılığıyla geçici bir ekip üyesine üretim ortamına dağıtım erişimi manuel olarak vermesi gibi görünebilir.
Gerçek Hayatta İşe Yarayan Bir Erişim Kontrol Politikası Nasıl Seçilir? Pipelines
Git'te Erişim Kontrolü
Katkıda bulunan, sürdürücü ve sürüm rollerini yönetmek için RBAC'yi kullanın. Korunan dallara birleştirme haklarını kilitleyin. İmzalı olmasını zorunlu kılın. commitve korumaları kimlerin atlayabileceğini sınırlandırır.
Örnek: GitHub Dal Koruma Kuralları
- Iste pull request Birleştirmeden önce yapılan incelemeler.
- Eski olanı reddet pull request yeni onaylar commititiliyorlar.
- İmza gereklidir. commits.
- Üretim açısından kritik öneme sahip depolar için DAC'ı atlayın. Yazma erişimini rastgele vermeyin.
Pipeline uygulama
Erişim kontrolünü zorunlu hale getirin pipelineSağlam bir Mac erişim kontrol modeli, CI işlerinin yalnızca ihtiyaç duydukları izinlerle sınırlandırılmasını sağlar.
- Sırları ortama göre ayırın.
- Her ortam için benzersiz belirteçler kullanın.
- Manuel çalıştırmaların üretimi etkilemesini önleyin.
Örnek: Bir CI işi, hazırlık ve üretim ortamlarında aynı dağıtım belirtecini yeniden kullanıyor ve yanlışlıkla test kodunu canlı ortama gönderiyor.
Token kapsamını kontrol etmek için Mac erişim denetimi kuralları ekleyin:
yaml env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }} if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' Gizlilik Kapsamı Örneği: Ortama Özgü Token Kullanımı
Ortam bazında sırların kapsamını doğru bir şekilde belirlemek son derece önemlidir. Kazara veya kötü niyetli ortamlar arası erişimi önleyin. Örneğin, geliştirme ortamı için kullanılan bir dağıtım belirteci, üretim ortamına dağıtım yapmak için asla kullanılmamalıdır.
GitHub Actions'ta erişim kontrolü politikası tabanlı denetimlerin gizli bilgi kullanımını nasıl izole ettiğine dair bir örnek aşağıda verilmiştir:
yaml env: DEPLOY_TOKEN_DEV: ${{ secrets.DEPLOY_TOKEN_DEV }} DEPLOY_TOKEN_PROD: ${{ secrets.DEPLOY_TOKEN_PROD }} jobs: deploy-dev: if: github.ref == 'refs/heads/dev' && github.actor == 'developer' runs-on: ubuntu-latest steps: - name: Deploy to Dev run: ./deploy.sh env: TOKEN: ${{ env.DEPLOY_TOKEN_DEV }} deploy-prod: if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' runs-on: ubuntu-latest steps: - name: Deploy to Prod run: ./deploy.sh env: TOKEN: ${{ env.DEPLOY_TOKEN_PROD }} Bu da şunu sağlar:
- Sadece geliştirici Bu rol, geliştirici belirteci (dev token) kullanarak dağıtımları tetikleyebilir. dev dalı.
- Sadece sürüm yöneticisi Bu rol, üretim belirteci (prod token) kullanarak üretim ortamına dağıtım yapabilir. ana dalı.
Bu tür sınırlı gizli kullanım, token sızıntılarının ortamlar arasında yayılma riskini azaltır ve en az ayrıcalık ilkesini uygular CI/CD pipelines Sıkı erişim kontrol politikaları izlenerek.
Nesne Erişim Kontrolleri
Zorunlu erişim kontrolü kullanarak yapıt kayıtlarını kilitleyin. CI/CD Yayınlama işini bireysel geliştiriciler değil, sistemler üstlenmeli.
RBAC kullanarak hangi ekiplerin belirli kayıt defterlerinden veri çekeceğini tanımlayabilirsiniz. Geliştiricilerin üretim paketlerine yalnızca okuma erişimine ihtiyacı olabilir.
json { "rules": [ { "action": "read", "resource": "npm-package:internal/*", "allowed_roles": ["developer", "qa"] }, { "action": "write", "resource": "npm-package:internal/*", "allowed_principals": ["ci-pipeline"] } ] } Geliştirme İş Akışlarında Sık Görülen Erişim Kontrolü Hataları
Aşırı İzin Verici Depo Erişimi
Sorun: Çok fazla kullanıcıya depolara yazma/yönetici erişimi vermek.
Nasıl Olur: Ekip üyeleri, yetkileri gözden geçirilmeden terfi ettiriliyor veya ekibe dahil ediliyor. Roller gereksiz yere karmaşıklaşıyor.
Saldırgan Saldırısı: Saldırganlar, çalıntı kimlik bilgileri veya sosyal mühendislik yöntemlerini kullanarak bu hesapları hedef alıyor. İçeri girdikten sonra, kötü amaçlı kodlar yerleştirebiliyor, arka kapılar oluşturabiliyor veya izleri gizlemek için geçmişi silebiliyorlar.
Geliştirme ve Üretim Ortamları Arasında Paylaşılan İzinler
Sorun: geliştirme ve üretime izin vermek pipelines paylaşım izinleri.
Nasıl Olur: Ekipler, aynı dağıtım belirtecini veya CI hizmet hesabını farklı ortamlarda yeniden kullanır.
Saldırgan Saldırısı: Geliştirme ortamındaki bir güvenlik açığı, saldırganlara üretim ortamına erişim imkanı sağlar. Zorunlu erişim kontrolü Bu durum, izinleri belirli ortamlara bağlayarak önlenebilir.
Manuel Yapı Yüklemeleri
Sorun: Üretim kayıt defterlerine manuel olarak dosya yüklemeye izin verilmesi.
Nasıl Olur: Geliştiriciler atlıyor pipelineHızlı çözümler veya acil yamalar için.
Saldırgan Saldırısı: Güvenliği ihlal edilmiş geliştirici makineleri, tüm güvenlik önlemlerini atlayarak kötü amaçlı yazılımı doğrudan yapıt depolama alanına yükleyebilir. CI/CD güvenlik kontrolleri.
Kayıt Politikası Kötüye Kullanım Riski: Yazılım tedarik zincirinde, ürünlerin manuel olarak yayınlanması kritik bir saldırı yüzeyi oluşturur. Saldırganlar, bu gevşekliği istismar ederek... erişim kontrolü politikaları Güvenilir paketlere veya konteyner imajlarına kötü amaçlı kod ekleyebilir ve bu da yaygın güvenlik ihlallerine yol açabilir. Son yazılım tedarik zinciri olayları, denetimsiz dosya yüklemelerinin nasıl hızla büyük güvenlik ihlallerine dönüşebileceğini ve sayısız kullanıcıyı ve sistemi etkileyebileceğini göstermiştir.
Örnek: anpm kayıt defterine tam erişime sahip bir stajyer, yanlışlıkla kararsız bir sürüm yayınlıyor. Eğer bir saldırgan bu stajyerin bilgisayarını ele geçirmiş olsaydı, bunun yerine kötü amaçlı yazılım yayınlayabilirdi.
Güçlü Erişim Kontrollerini Uygulamaya Yönelik Pratik Adımlar
- Rolleri tam izinlerle eşleştirin, tek tip rol yaklaşımından vazgeçin.
- Erişim kontrolü politikası denetimlerini otomatikleştirin. CI/CD pipelines
- Kayıt defterlerini zorunlu erişim kontrolüyle kilitleyin.
- Kritik sistemlere erişimi sürekli olarak kaydedin ve izleyin.
- Erişim kontrol politikalarına kod gibi yaklaşın. Her yanlış adım istismar edilebilir.
Xygeni'nin Rolü: DevOps İş Akışlarında Erişim Politikalarının Uygulanması ve İzlenmesi
Xygeni Bu, DevSecOps'ta günlük hayatta karşılaşılan erişim kontrolü politikası uygulama zorluklarını çözerek, zorunlu erişim kontrolünü teoriden pratiğe dönüştürmenize yardımcı olur. pipelines.
- Git'e Aşırı Yetki Verilmesinden Kaynaklanan Erişim Sorununu Çözme: Xygeni, incelenmemiş rol atamaları veya eksik dal korumaları gibi RBAC ihlalleri için Git depolarını sürekli olarak izler. Erişim kontrol politikaları tanımlanmış kurallardan saparsa uyarı verir ve yanlışlıkla birleştirmeleri veya kötü amaçlı çekme isteklerini önlemek için düzeltici eylemler uygular.
- Karantina CI/CD Pipelines: CI işlemleri bazen amaçlanandan daha geniş kapsamlarla çalışır. Xygeni bunu algılar. CI/CD İş taleplerini veya kendilerine atanan rollerin ötesindeki işlemleri tespit ederek, yetki alanı genişlemesini ve ayrıcalıkların kötüye kullanılmasını gerçek zamanlı olarak belirler. Bu, MAC erişim kontrolü ilkelerinin uygulanmasına yardımcı olur. pipelineErişimi, işin kimliği ve amacına sıkı sıkıya bağlayarak.
- Yapıt Yayınlama Kontrollerinin Uygulanması: Geliştiriciler hala manuel olarak dosya veya resim yüklüyorsa, Xygeni buna son verir. Kayıt defteri düzeyinde zorunlu erişim kontrolü uygulayarak yalnızca doğrulanmış kullanıcıların erişmesine izin verir. pipeline Kimlikler artık yayınlanabilir içerikler oluşturabilir. Üretim kayıtlarına insan eliyle yükleme yapılmasına gerek kalmayacak.
- Erişimi İzleme ve Anormallikleri Belirleme: Xygeni ile kimin neye, ne zaman ve nasıl eriştiğini görebilirsiniz. Olağandışı davranışları tespit etmek, yanlış yapılandırmaları işaretlemek ve olay sonrası analizde yardımcı olmak için gizli bilgilerin kullanımını, depo erişimini ve kayıt defteri etkileşimlerini sürekli olarak izler.
Alt satır: Xygeni, erişim kontrol politikasına otomasyon ve uygulama getirerek DevOps ortamınızın yavaşlamadan güvenli kalmasını sağlar.
Dolayısıyla, Erişim Kontrolünü şu şekilde ele alın: Code Security
Uygulamanızı çalıştırma yetkisine veya altyapı erişimine sahip herkes, kazaen veya kasıtlı olarak uygulamanızı bozabilir. Bu nedenle, son derece sağlam bir erişim kontrol politikası isteğe bağlı değildir. Rolleri doğru şekilde atamak için RBAC kullanın. Kritik sistemlere zorunlu erişim kontrolü uygulayın. Üretim ortamları için DAC'yi tamamen atlayın. Erişim kontrol politikalarını sisteminize entegre edin. DevSecOps en iyi uygulamaları. Otomatikleştirin. İzleyin. Uygulayın.
TL; DRİyi uygulanan bir erişim kontrol politikası, kod tabanınızı, bileşenlerinizi ve altyapınızı otomatik olarak daha güvenli hale getirir.
