Amazon Verified Permissions ile Uygulamalarınızda Yetkilendirmeyi Yönetme Yönteminizi Basitleştirin – Artık Genel Olarak Kullanılabilir

Orijinal makale: Link (Danilo Poccia)

Yeni bir uygulama geliştirirken veya mevcut bir uygulamayı yeni bir ortama entegre ederken, kullanıcı kimlik doğrulaması ve yetkilendirmesinin doğru bir şekilde uygulanması için önemli bir çaba gerekir. Geçmişte kendi kimlik doğrulama sisteminizi oluştururdunuz, ancak bugün Amazon Cognito gibi bir harici kimlik sağlayıcı kullanabilirsiniz. Yine de, yetkilendirme mantığı genellikle kodda uygulanır.

Bu, tüm kullanıcılara iş fonksiyonları için bir rol atanmasıyla yeterince basit bir şekilde başlayabilir. Ancak, zamanla bu izinler giderek daha karmaşık hale gelir. İzinler daha ayrıntılı hale geldikçe rol sayısı da artar. Yeni kullanım örnekleri, özel izinlere olan ihtiyacı artırıyor. Örneğin, bir kullanıcı farklı bir roldeki başka bir kullanıcıyla bir belge paylaşabilir veya bir destek temsilcisine, bir sorunu çözmek için bir müşteri hesabına geçici erişim gerekebilir. Kodda izinleri yönetmek hatalara açıktır ve izinleri denetlerken ve kimin neye erişimi olduğuna karar verirken, özellikle de bu izinler farklı uygulamalarda ve birden çok programlama dilinde ifade edildiğinde önemli zorluklar ortaya çıkarır.

re:Invent 2022’de, uygulamalarınız için her ölçekte kullanılabilecek ayrıntılı bir izin yönetimi ve yetkilendirme hizmeti olan Amazon Verified Permissions‘ı (Amazon Doğrulanmış İzinler) ön izleme aşamasında kullanıma sunduk. Amazon Verified Permissions, izinleri bir politika deposunda merkezileştirir ve geliştiricilerin, uygulamalarında kullanıcı işlemlerini yetkilendirmek için bu izinleri kullanmasına yardımcı olur. Bir kimlik sağlayıcının kimlik doğrulamayı basitleştirmesine benzer şekilde, bir politika deposu, yetkilendirmeyi tutarlı ve ölçeklenebilir bir şekilde yönetmenize olanak tanır.

Ayrıntılı izinleri tanımlamak amacıyla Amazon Verified Permissions, erişim kontrolü için açık kaynaklı bir politika dili ve yazılım geliştirme kiti (SDK) olan Cedar‘ı kullanır. Yetkilendirme modeliniz için kimlik (principal) türleri, kaynak türleri ve geçerli eylemler açısından bir şema tanımlayabilirsiniz. Bu şekilde, bir politika oluşturulduğunda, yetkilendirme modelinize göre doğrulanır. Şablonları kullanarak benzer politikaların oluşturulmasını basitleştirebilirsiniz. Politika deposundaki değişiklikler, değişiklikleri kimin ne zaman yaptığını görebilmeniz için denetlenir.

Ardından, erişim isteklerini yetkilendirmek için uygulamalarınızı AWS SDK’ler aracılığıyla Amazon Verified Permissions’a bağlayabilirsiniz. Her bir yetkilendirme talebi için ilgili politikalar alınır ve eyleme izin verilip verilmediğini belirlemek için değerlendirilir. İzinlerin amaçlandığı gibi çalıştığını doğrulamak için bu yetkilendirme isteklerini çoğaltabilirsiniz.

Bugün, Amazon Verified Permissions’ın AWS Management Console‘da yeni yetenekler ve basitleştirilmiş bir kullanıcı deneyimi ile genel kullanıma sunulduğunu paylaşmaktan mutluluk duyuyorum.

Pratikte bunu nasıl kullanabileceğinizi görelim.

Amazon Verified Permissions ile Politika Deposu Oluşturma

Amazon Verified Permissions konsolunda Create policy store (Politika deposu oluştur) seçiyorum. Politika deposu, politikaları ve şemayı depolayan mantıksal bir kapsayıcıdır. Yetkilendirme kararları, bir politika deposunda bulunan tüm politikalara dayalı olarak verilir.

Yeni politika deposunu yapılandırmak için farklı yöntemler kullanabilirim. Kılavuzlu bir kurulum, örnek bir politika deposu (fotoğraf paylaşım uygulaması, çevrimiçi mağaza veya görev yöneticisi gibi) veya boş bir politika deposu (ileri düzey kullanıcılar için önerilir) ile başlayabilirim. Guided setup (Kılavuzlu kurulum) seçiyorum, şemam (MyApp) için bir ad alanı giriyorum ve Next‘i (İleri) seçiyorum.

Kaynaklar, öznelerin (principal) işlem yapabileceği nesnelerdir. Uygulamamda, Documents (kaynakları) oluşturabilen, okuyabilen, güncelleyebilen ve silebilen Users (özneler) var. Documents kaynak türünü tanımlamaya başlıyorum.

Kaynak türünün adını giriyorum ve gerekli iki özelliği ekliyorum:

owner (String) belgenin sahibinin kim olduğunu belirtmek için.
isPublic (Boolean) herkesin okuyabileceği genel belgeleri işaretlemek için.

Document kaynak türü için dört eylem belirtiyorum:

DocumentCreate
DocumentRead
DocumentUpdate
DocumentDelete

Bu eylemleri Documents üzerinde kullanacak özne türünün adı olarak User giriyorum. Sonra Next‘i seçiyorum.

Şimdi, User özne türünü yapılandırıyorum. Harici bir kimlik kaynağını entegre etmek için özel bir yapılandırma kullanabilirim, bu çalışma için daha önce oluşturduğum bir Amazon Cognito kullanıcı havuzunu kullanıyorum. Connect user pool‘u (Kullanıcı havuzunu bağla) seçiyorum.

İletişim kutusunda kullanıcı havuzunun bulunduğu AWS Bölgesini seçip kullanıcı havuzu kimliğini (User pool ID) giriyorum ve Connect‘i (Bağlan) seçiyorum.

Artık Amazon Cognito kullanıcı havuzu bağlandığına göre, istemci uygulama kimliklerini doğrulayarak başka bir koruma düzeyi ekleyebilirim. Şimdilik bu seçeneği kullanmamayı tercih ediyorum.

Principal attributes (Özne özellikleri) bölümünde, politikalarımda öznitelik tabanlı erişim kontrolü için kullanmayı planladığım öznitelikleri seçiyorum. OpenID Connect spesifikasyonuna göre son kullanıcıyı tanımlamak için kullanılan sub (konu) öğesini seçiyorum. Daha fazla özellik seçebilirim. Örneğin, yalnızca e-postası doğrulanmış Amazon Cognito kullanıcılarına izin vermek için bir politikada email_verified kullanabilirim.

Politika deposu oluşturmanın bir parçası olarak, danilop kullanıcısına doc.txt belgesine okuma erişimi vermek için bir ilk politika oluşturuyorum.

Aşağıdaki kodda, konsol bana Cedar dilini kullanarak ortaya çıkan politikanın bir ön izlemesini veriyor.

permit(
  principal == MyApp::User::"danilop",
  action in [MyApp::Action::"DocumentRead"],
  resource == MyApp::Document::"doc.txt"
) when {
  true
};

Son olarak, Create policy store (Policy store oluştur) seçiyorum.

Politika Deposuna İzinler Ekleme

Artık politika deposu oluşturulduğuna göre, gezinti bölmesinde Policies (Politikalar) seçiyorum. Create policy (Politika oluştur) açılır menüsünde, Create static policy (Statik politika oluştur) seçiyorum. Statik bir politika, değerlendirilmesi için gereken tüm bilgileri içerir. İkinci politikamda, herhangi bir kullanıcının genel belgeleri okumasına izin veriyorum. Varsayılan olarak her şey yasaktır, bu nedenle Policy Effect‘te Permit‘i (İzin Ver) seçiyorum.

Policy scope‘ta (Politika kapsamı), All principals (Tüm özneler) ve All resources (Tüm kaynaklar) seçili bırakıyorum ve DocumentRead eylemini seçiyorum. Policy bölümünde, isPublic‘in true değerine eşit olduğu kaynaklara izinleri sınırlamak için when koşul yan tümcesini değiştiriyorum:

permit (
  principal,
  action in [MyApp::Action::"DocumentRead"],
  resource
)
when { resource.isPublic };

Politika için bir açıklama giriyorum ve Create policy seçiyorum.

Üçüncü politikam için, bir belgenin sahibine tam erişim sağlamak için başka bir statik politika oluşturuyorum. Yine, Policy Effect‘te Permit‘i seçiyorum ve Policy scope‘ta, All principals ve All resources‘u seçili bırakıyorum. Bu sefer ayrıca All actions‘ı (Tüm eylemler) seçili bırakıyorum.

Policy bölümünde, owner‘ın asılın sub kısmına eşit olduğu kaynaklara izinleri sınırlamak için when koşulu yan tümcesini değiştiriyorum:

permit (principal, action, resource)
when { resource.owner == principal.sub };

Uygulamamda, bir belgenin sahibi olmayan belirli kullanıcılara okuma erişimi vermem gerekiyor. Bunu basitleştirmek için bir politika şablonu oluşturuyorum. Politika şablonları, özne veya kaynak gibi bazı değerleri için yer tutucular kullanan bir şablondan politikalar oluşturmamı sağlıyor. Bir şablondaki yer tutucular, ? karakteri ile başlayan anahtar sözcüklerdir.

Gezinme bölmesinde, Policy templates (Politika şablonları) ve ardından Create policy template (Politika şablonu oluştur) seçiyorum. Bir açıklama giriyorum ve aşağıdaki politika şablonu gövdesini kullanıyorum. Bu şablonu kullanırken ?principal ve ?resource yer tutucuları için değer belirleyebilirim.

permit(
  principal == ?principal,
  action in [MyApp::Action::"DocumentRead"],
  resource == ?resource
);

Politika şablonunun oluşturulmasını tamamlıyorum. Şimdi, politikaların oluşturulmasını basitleştirmek için şablonu kullanıyorum. Gezinme bölmesinde Policies ve ardından Create policy açılır menüsünde Create a template-linked policy‘i seçiyorum. Az önce oluşturduğum politika şablonunu seçiyorum ve Next‘i seçiyorum.

Belirli bir belge (new-doc.txt) için bir kullanıcıya (danilop) erişim vermek için aşağıdaki değerleri iletiyorum (MyApp‘in, politika deposunun ad alanı olduğunu unutmayın):

Principal için: MyApp::User::"danilop"
Resource için: MyApp::Document::"new-doc.txt"

Politika oluşturma işlemini tamamlıyorum. Şimdi politikaların beklendiği gibi çalışıp çalışmadığını test etme zamanı.

Politikaları Konsolda Test Etme

Uygulamalarımda, yetkilendirme isteği çalıştırmak için AWS SDK’lerini kullanabilirim. Konsol, uygulamalarımın ne yapacağını simüle etmek için bir yol sağlar. Gezinme bölmesinde Test bench‘i seçiyorum. Testi basitleştirmek için Visual mode (Görsel mod) kullanıyorum. Alternatif olarak, SDK’lerde olduğu gibi aynı JSON sözdizimini kullanma seçeneğine sahibim.

Principal olarak, janedoe kullanıcısını geçiyorum. Resource olarak requirements.txt kullanıyorum. Bu halka açık bir belge değildir (isPublic değeri false‘tur) ve owner özniteliği janedoe‘nun sub özelliğine eşittir. Action için MyApp::Action::"DocumentUpdate" seçeneğini seçiyorum.

Bir yetkilendirme isteği çalıştırırken, istekle ilişkili asıllar ve kaynaklar hakkında daha fazla bilgi içeren Additional entities‘i (Ek varlıklar) iletebilirim. Şimdilik bu kısmı boş bırakıyorum.

Mevcut politikalara göre kararı görmek için üst kısımda Run authorization request‘i (Yetkilendirme talebini çalıştır) seçiyorum. Beklendiği gibi, karar allow, yani “izin ver”dir. Burada, yetkilendirme talebinin hangi politikaları karşıladığını da görüyorum. Bu durumda, belgenin sahibine tam erişim sağlayan politikadır.

Diğer değerleri test edebilirim. Belgenin sahibini ve eylemi DocumentRead olarak değiştirirsem, karar deny, yani “reddet”tir. Daha sonra isPublic kaynak özniteliğini true olarak ayarlarsam, tüm kullanıcıların genel belgeleri okumasına izin veren bir politika olduğu için karar allow‘dur (izin ver).

Grupları İzinlerde İşleme

Uygulamamdaki yönetici kullanıcıların herhangi bir belgeyi silebilmesi gerekir. Bunu yapmak için yönetici kullanıcılar için bir rol oluşturuyorum. Önce gezinti bölmesinde Schema‘yı ve ardından Edit schema‘yı (Şemayı düzenle) seçiyorum. Varlık türleri listesinde yeni bir tane eklemeyi seçiyorum. Type name (Tür adı) olarak Role kullanıyorum ve ekliyorum. Ardından, varlık türlerinde User seçip, üst öge olarak Role eklemek için düzenliyorum. Değişiklikleri kaydedip şu politikayı oluşturuyorum:

permit (
  principal in MyApp::Role::"admin",
  action in [MyApp::Action::"DocumentDelete"],
  resource
);

Test bench‘te, jeffbarr kullanıcısının doc.txt kaynağını silip silemeyeceğini (DocumentDelete) kontrol etmek için bir yetkilendirme isteği çalıştırıyorum. Kaynağın sahibi olmadığı için istek reddedilir.

Şimdi, Additional entities‘de, tanımlayıcı olarak jeffbarr ile MyApp::User varlığını ekliyorum. Üst öğe olarak, tanımlayıcı admin ile MyApp::Role varlığını ekliyorum ve onaylıyorum. Konsol, MyApp::Role::"admin" varlığına başvurulduğu konusunda beni uyarıyor, ancak ek varlık verilerine dahil edilmiyor. Eklemeyi ve bu sorunu düzeltmeyi seçiyorum.

Yeniden bir yetkilendirme isteği çalıştırıyorum ve artık buna izin veriliyor çünkü ek varlıklara göre asıl (jeffbarr) bir admin.

Uygulamanızda Amazon Verified Permissions Kullanma

Uygulamalarımda, isAuthorized API eylemini (veya asıl dış kimlik kaynağından geliyorsa isAuthrizedWithToken) kullanarak bir yetkilendirme isteği çalıştırabilirim.

Örneğin, aşağıdaki Python kodu, bir kullanıcının bir belgeye okuma erişimi olup olmadığını kontrol etmek için AWS SDK for Python’u (Boto3) kullanır. Yetkilendirme isteği az önce oluşturduğum politika deposunu kullanıyor.

import boto3
import time

verifiedpermissions_client = boto3.client("verifiedpermissions")

POLICY_STORE_ID = "XAFTHeCQVKkZhsQxmAYXo8"

def is_authorized_to_read(user, resource):

    authorization_result = verifiedpermissions_client.is_authorized(
        policyStoreId=POLICY_STORE_ID, 
        principal={"entityType": "MyApp::User", "entityId": user}, 
        action={"actionType": "MyApp::Action", "actionId": "DocumentRead"},
        resource={"entityType": "MyApp::Document", "entityId": resource}
    )

    print('Can {} read {} ?'.format(user, resource))

    decision = authorization_result["decision"]

    if decision == "ALLOW":
        print("Request allowed")
        return True
    else:
        print("Request denied")
        return False

if is_authorized_to_read('janedoe', 'doc.txt'):
    print("Here's the doc...")

if is_authorized_to_read('danilop', 'doc.txt'):
    print("Here's the doc...")

Bu kodu çalıştırıyorum ve tahmin edebileceğiniz gibi çıktı daha önce yapılan testlerle uyumlu.

Kullanılabilirlik ve Fiyatlandırma

Amazon Verified Permissions, bugün Çin merkezli olanlar hariç tüm ticari AWS Bölgelerinde kullanıma sunulmuştur.

Amazon Verified Permissions ile, hizmete yapılan yetkilendirme isteklerinin ve API çağrılarının sayısına göre yalnızca kullandığınız kadar ödeme yaparsınız. Daha fazla bilgi için Amazon Verified Permissions fiyatlandırmasına bakın.

Amazon Verified Permissions kullanarak, Cedar politika dilini kullanarak ayrıntılı izinleri yapılandırabilir ve uygulamalarınızın kodunu basitleştirebilirsiniz. Bu şekilde, izinler merkezi bir depolamada tutulur ve denetlenmesi daha kolaydır. Burada, Cedar’ı otomatik akıl yürütme ve diferansiyel test ile nasıl oluşturduğumuz hakkında daha fazla bilgi edinebilirsiniz.

Amazon Verified Permissions ile uygulamalarınız için yetkilendirmeyi yönetin.

AWS Türkçe Blog

Amazon Verified Permissions ile Uygulamalarınızda Yetkilendirmeyi Yönetme Yönteminizi Basitleştirin – Artık Genel Olarak Kullanılabilir