AWS IAM (Identity Access Control Manager) & AWS Cognito
Herkese merhabalar, bu makalemizde sizlere AWS IAM (Identity and Access Management) diğer bir adıyla “Kimlik ve Erişim Yönetimi” servisinden ve kullanıcı güvenliği için Cognito servisinden kısaca bahsedeceğim.
IAM, AWS üzerindeki şirket organizasyonu içerisinde bulunan kullanıcıların şirket kaynaklarına (Data, Storage, Application vb.) erişimin kontrol edilmesini ve kimlik denetimi sağlayan bir servis. Günümüzde şirket çalışanlarının herhangi bir yerden şirket kaynaklarına erişimleri mümkün hale geldi. Bu durum çalışanları on-premises güvenlik çözümlerinin dışında bırakmış ve bu durum güvensiz bir ortam yaratmış olsa da, oluşan güvensiz ortamın açığının kapatılması adına IAM, güvenlik tarafında da çok önemli bir rol oynamaktadır. Peki IAM in güvenlik konusunda hangi politikaları uyguladığına bakacak olursak karşımıza Multi-Factor Authentication (Çok Faktörlü Kimlik Doğrulaması) çıkacaktır. IAM servisi MFA ve güçlendirilmiş encryption ile kullanıcıları güçlü bir kontrolden geçirerek erişimlerini kontrol altına alır ve kolaylıkla monitör edilebilir bir yapı haline getirir. IAM servisini anlatırken bilmemiz gereken temel kavramlara da değinmek gerekir. User, Group ve Role tanımları ve örnek uygulamaları bize IAM servisinin tam olarak ne olduğu hakkında daha fazla fikir verecektir.
IAM Users:
AWS üzerinde oluşturduğumuz kullanıcılardır. Users; kullanıcıların AWS yönetim konsoluna giriş yapabilmelerini ve yetkileri dahilindeki kaynaklara ulaşabilmelerini sağlamaktır. Uygulamalı olarak ;
AWS Console hesabımıza giriş yaparak ve Services menüsünü kullanarak IAM servisine geldiğimizde karşımıza çıkan ekrandan Users ve Add Users seçenekleri ile ilerleyip (Figure 1.1) kullanıcı ekleme bölümüne geliyoruz. Burada kullanıcımızın bilgilerini girerek ilerliyoruz. Eğer aynı anda birden fazla kullanıcı ekleyeceksek (bu kullanıcıların aynı erişim türü ve izinlerine sahip olması gereklidir) “Add another user” diyerek ekleyebiliriz.
AWS Access Type bölümünden kullanıcıların AWS’ye nasıl erişeceğini seçiyoruz. Eğer Programmatic access seçeneği seçilirse kullanıcı için bir Key ID ve Secret Access Key oluşturuyor. Bunu AWS API, CLI, SDK gibi geliştirme araçlarına erişebilmek için kullanıyoruz. Diğer bir seçenek ise AWS Management Console Access ile de kullanıcılarımıza AWS Yönetim Konsolu üzerinden oturum açmaya izin verdiğimiz şifre bilgilerini belirliyoruz. (Figure 1.2)
Bir sonraki sekmede ise karşımıza izinleri ayarlayacağımız bölüm geliyor. Bu bölümde kullanıcıyı mevcut olan bir gruba ya da yeni bir gruba mı ekleyeceğiz, mevcut bir kullanıcı ile aynı izinleri mi vereceğiz yoksa mevcut policies’lerden (kendi oluşturduğunuz ya da AWS’in sizin için oluşturduğu policies) mi seçim yapacağımızı belirliyoruz. Burada IAM Groups kavramı karşımıza çıkıyor. Peki genel anlamda IAM Groups nedir?
Birden fazla IAM user’ından oluşur. Yetki dağıtımı yaparken her kullanıcıya ayrı ayrı, aynı yetkileri vermektense aynı grup üyelerinden oluşan kullanıcıları tek bir grup altında toplayarak tüm grup üyelerinin aynı yetkiler ile sisteme login olmalarını sağlayabiliriz. Bunun dışında ekibe yeni dahil olan bir kullanıcıya herhangi bir yetki ataması yapmadan grup üyeliği ataması yaparak aynı yetkileri almasını sağlayabiliriz.
Bizim hiyerarşik yapımız, oluşturacağımız kullanıcıyı doğrudan etkilediği için, bu kullanıcımızın belirli bir hiyerarşide mi yer aldığı yoksa bireysel olarak farklı poliçelere mi ihtiyaç duyduğunu düşünerek izinleri ayarlıyoruz (ben kullanıcımı bir gruba dahil etmeyi tercih ederek devam ettim). (Figure 1.3)
Yeni oluşturacağımız hiyerarşide mevcutta bir kullanıcı grubu olmadığını varsayarsak, buradan da bir grup oluşturabiliriz. “Create Group” diyerek devam ediyoruz. Bu seçenek ile ilerlediğimizde bizi (Figure 1.4) grup oluşturma ekranı karşılayacaktır. Burada da grup üzerinden poliçe yetki ve kısıtlamaları belirleyerek ilerliyoruz.
Eğer yalnızca bu kullanıcı için işlem yapmak istiyorsanız, yapınızda çok fazla kullanıcı yoksa ya da test ortamında demo yapıyorsanız mevcut bir poliçeyi atayarak ilerleyebilirsiniz (Figure 1.5)
Mevcutta bulunan aynı yetkilere sahip bir kullanıcımız var ise izinlerimizi bu kullanıcıdan da kopyalayabiliriz. (Figure 1.6)
Bir sonraki sekmede karşımıza opsiyonel olarak bizden Tag eklememiz isteniyor. Buradaki önemli nokta; eklediğimiz Key/Value. Bu, oluşturduğumuz kullanıcının erişimini düzenlemek, izlemek veya kontrol etmek için kullandığımız değerlerdir.(Figure 1.7) Bu konuda daha fazla bilgi için buradaki link üzerinden daha detaylı bilgi alabilirsiniz.
Kullanıcımızı bu aşamada oluşturduğumuzu varsayarsak, bu kullanıcı ile ilgili nereden, nasıl, hangi kullanıcı adı ve şifre ile bağlanacağıyla ilgili bilgileri bu ekrandan (Figure 1.8) alabiliyoruz. Kullanıcı bilgilerini .csv olarak bilgisayarımıza indirebilir ya da bu bilgileri mail olarak kullanıcımıza gönderebiliriz. (Figure 1.9)
Uygulamada, kullanıcımızın şifre bilgisini AWS oluştursun komutu ile bize otomatik bir şifre kombinasyonu yarattı ancak mailde bize bu bilgi verilmedi. Bu durumda sistem yöneticimizden AWS console hesabımızın şifresini talep etmemiz gerekiyor. (Figure 1.9)
Son olarak tüm işlemlerimizi yaptığımızda IAM servisimizin altında Users sekmesinde kullanıcıyı oluşturduğumuzu görebileceksiniz.(Figure 1.10)
Yeni kullanıcımız ile giriş yaptığımızda, AWS tarafından atanan şifreyi, kendi şifre politikalarımız çerçevesinde güncellememiz gerekiyor. (Figure 1.11)
İlk login ekranımızla karşılaştık. (Figure 1.12) Uygulamamızın kalan kısımlarına bu hesap üzerinden devam edeceğiz.
IAM Roles:
IAM Rol’ü, Users’a çok benzeyen kavramdır ancak Users’dan farkı, Role’lerin kendilerine ait şifreleri ya da key’leri yoktur. Role’ler, User’lar gibi sistemdeki bir kullanıcıyı diğerlerinden farklı kılmak dışında, birden fazla kullanıcıya atanabilme özelliğine sahiptir. Kısaca bir “root” role’ü olduğunu varsayarsak, root role’üne sahip olan her kullanıcı, sistemde root yetkilerine sahip olacaktır. Uygulamamızda daha anlaşılır bir şekilde göreceğiz.
IAM Servisimizin altında Roles sekmesine gelerek “Create Role” dediğimizde bu şekilde bir sekme(Figure-2.1) ile karşılaşıyoruz. Sekmede gördüğümüz güvenilen varlık türlerinden bahsedecek olursak AWS Service Role seçimi; AWS hizmetlerinin bizim adımıza işlem gerçekleştirmesine izin vermemiz için seçmemiz gereken işlemdir.
Burada oluşturacağımız Role, hangi AWS hizmetine hangi kullanıcı için ne tür izinler (Permissions) vermek istiyoruz sorusunun cevabını veriyor bize. Burada karşımıza çıkan Permissions kavramını kısaca tanımlamak gerekirse; Permissions, AWS kaynakları üzerinde hangi kullanıcıların ne gibi haklara sahip olacaklarını belirlememizi sağlar. AWS’de yeni oluşturulan kullanıcıların herhangi bir izini olmaz, bunu permissions olarak atamanız gerekmektedir. AWS üzerinde sizin oluşturacağınız Policy’leri user’lara, user’ların dahil olduğu gruplara veya oluşturduğumuz role’lere atayarak, kullanıcılara izin verdiğimiz ya da “izin verilmesi gereken” çerçevede kullanım hakkı atayabilirsiniz.
Another AWS account sekmesi ise başka AWS hesaplarındaki kullanıcıların bizim kaynaklarımıza erişeceği izninin verildiği sekmedir (Trusted Account). Burada atlanmaması gereken bir husus; örneğin 2. bir AWS hesabı ile güven ilişkisi kurduğunuzda ve bu 2. AWS hesabı asıl AWS hesabında yeni bir kaynak oluşturduğunda bu kaynağın sahibi konumundadır, kaynak sahibi aynı zamanda kimlerin erişebileceğini de denetler. Daha detaylı bilgi için:
AWS’in bir diğer trusted yapısı olan Web Identity, belirtilen harici bir Web ID ya da OpenID Connect gibi sağlayıcılar tarafından federe edilen kullanıcıların, hesabınızda işlem yapmak için bu rolü kullanmasına izin verilen güven ilişkisidir. Bu yapıyı kullanabilmek için belirli ön koşullar bulunmaktadır. Daha detaylı bilgi için
Kimlik sağlayıcılar ve federasyon kullanıcı rehberini de inceleyebilirsiniz.
Son sekmede ise AWS hesabınızda IAM kullanıcıları oluşturmak yerine SAML 2.0 federasyonunu kullanabilirsiniz. Bir kimlik sağlayıcısı ile kullanıcı kimliklerinizi AWS dışında yönetebilir ve bu harici kullanıcı kimliklerine hesabınızdaki AWS kaynaklarına erişme izni verebilirsiniz. (Web Identity’ de olduğu gibi ön koşullar vardır.)
Örneğimize geri dönecek olursak; Role atama ekranında AWS Services altındaki EC2 rolünü tam yetki ile kullanabilecek kullanıcımızın rol atamasını yapıyoruz. EC2 seçtikten sonra ileri diyerek Permissions(izinler) ekranına geliyoruz(Figure 2.2). Burada seçtiğimiz “AmazonEC2FullAccess” policy’si bizim role atayacağımız kullanıcıya istediğimiz tam yetkiyi verecek.
Dilersek bu noktada da oluşturacağımız Role’ a Create Policy diyerek yeni bir policy yaratabiliriz. (Figure 2.3)
Bir sonraki sekmede (Figure 2.4) oluşturduğumuz Policy mizin atamasini gerçekleştiriyoruz. Policy eklemesini yaparken bir grup ataması gerçekleştirdik.
Bu aşamada (Figure 2.5) atadığımız rolün Tag atamalarını gerçekleştiriyoruz.
Tüm işlemlerimiz bittikten sonra yaptığımız işlemleri göreceğimiz ekran ile karşılaşıyoruz ve oluşturduğumuz Role’ e isim ve açıklama giriyoruz.(Figure 2.6)
Role oluşturma işlemimizi gerçekleştirdikten sonra arama çubuğundan atadığımız role ismi ile arama yaparak oluşturduğumuz rolleri görebilir ve düzenleyebiliriz. (Figure 2.7)
Policies:
Policy bir veya birden fazla izinlerin tanımlandığı dokümandır. Bir kullanıcıya, gruba veya role atayabileceğiniz AWS izinlerini tanımlar. Id, Statement, Sid, Effect, Principal, Action, Resource, Condition gibi elementleri vardır. Genel hatlarıyla örnek bir Policy oluşturup uygulamalı olarak inceleyelim.
AWS Services altından IAM servisinin altında, Policies sekmesine geldiğimizde karşımıza bir çok Policy çıkmaktadır. Eğer işimize yaradığını düşündüğümüz bir policy var ise (Figure 3.1)onu kullanıcımıza, gruplarımıza ya da bir role atayabilir ya da yeni bir policy yaratıp atamalarımızı gerçekleştirebiliriz.
Bu ekranda öncelikle hangi servise atama yapacağımızı daha sonra seçtiğimiz servis üzerinde hangi erişim yetkilerini vereceğimizi seçiyoruz. Ben örneğimizde EC2 servisi için tüm erişim haklarına sahiplik verecek bir policy oluşturmayı tercih ettim (Figure 3.2)
EC2 Servisime tüm yetkilerin atamasını gerçekleştirdikten sonra karşımıza isteğin hangi koşullarda aktif olması gerektiğini soruyor.(Figure 3.3) Biz bu kontrolleri sağlarken güvenlik politikalarımız gereği seçim yapmalı ve ilerlemeliyiz. MFA(Multi-Factor Authentication), Source IP seçimlerini yapabilir ya da farklı bir koşul(condition) ekleyebiliriz.
Dilersek bu oluşturacağımız policy’i json formatında belirli kurallar çerçevesinde kendimiz de yazabiliriz ancak bilmemiz gereken anahtar kelimeler mevcuttur. Version, Policies, Id, Statement, Sid, Effect, Principal, NotPrincipal, Action, Resource ve Condition. (Figure 3.4)
Kendi şifremizi belirlemek için örnek bir policy.(Sample 1.1)
Policy yazma işlemimizi bitirdikten sonra, Policy mizin genel hatlarıyla görünümü ve isimlendirdiğimiz bölüme geliyoruz.(Figure 3.5) Burada gerekli isimlendirme ve açıklamaları yazdıktan sonra Create diyerek policy mizi oluşturuyoruz.
Dilersek daha sonra oluşturduğumuz isim ile arama yaparak policy izinleri yönetebilir ya da düzenleyebiliriz.(Figure 3.6)
Policy mizi oluşturduktan sonra atama yapmamız gerekiyor. Bu işlemi Actions sekmesi altından gerekli kullanıcılara, gruplara veya rollere atayabiliriz. (Figure 3.7)
Bu bilgilerden sonra, IAM servisinin avantajları hakkında kısaca söz etmek gerekirse; merkezi yetki kontrolü, IT süreçlerinin kolaylaştırılması, kullanıcı deneyiminin kolaylaştırılması (özellikle her kullanıcı için her platforma ayrı ayrı şifre tanımlamaları konusunda identity profile sayesinde tek bir profil üzerinden tüm uygulamalara erişim sağlaması başarılı yönlerinden birisi. Kaldı ki kullanıcılara tanımlanan uygulama hesaplarının şifrelerinin her platformda farklı olması bir challenge haline gelmiş durumda.) gibi sıralanabilir.
IAM servisinde yönetebileceğimiz bir diğer hizmet ise Password Policy’ dir.
Account settings diyerek Password Policy’ lere genel bir bakış atalım.(Figure 4.1) Set password policy diyerek yeni bir şifre policy oluşturalım. Karşımıza çıkan ekranda minimum şifre uzunluğu, parola süresi, aynı parolanın yeniden kullanılmasını engellemek gibi çeşitli gereksinimler mevcut. Tabiki de şirketinizin şifre politikalarına uygun şekilde gereksinimler belirlemeniz gerekmektedir.
NOT: örnekte maksimum değerler gösterilmiştir.
Örneğin; şirketinizin minimum şifre uzunluğu 8 ve alfanumerik karakterler barındırmak zorundadır, parola zaman aşımı 90 gündür, kullanıcının kendi şifrelerini belirleyebilir gibi kriterlere uygun bir yapı oluşturmanız gerekmektedir.(Figure 4.2)
AMAZON Cognito
Kullanıcı yaratma, oturum açma ve web-mobil uygulamalarımıza erişim sağlama işini hızlı ve kolay bir şekilde yönetmemizi sağlar. Amazon Cognito, milyonlarca kullanıcıya Facebook, Google, Amazon gibi 3. parti sosyal kimlik sağlayıcılarıyla ve SAML2.0 üzerinden kurumsal kimlik sağlayıcılarıyla oturum açmayı destekliyor. Bunu şu şekilde özetleyebiliriz. AWS üzerinde mobil uygulamamızın olduğunu düşünelim. Uygulamayı mobil cihazlarına yükleyecek kişiler kullanıcı adı ve şifre ile uygulamaya giriş yapsın istiyoruz. Kullanıcı adı ve şifre yaratma işini manuel yaptırmak dışında sosyal medya hesabıyla kayıt olma seçeneğini bize sunuyor. Biz bu işlemlerin hepsini IAM altında oluşturacağımız User ve Groups altından yönetebiliyoruz 2 farklı kullanıcı ya da group oluşturup AWS Cognito pool ayarlarından rolleri ayarlayarak kullanıcılarımızdan/gruplarımızdan birine Cognito üzerinde yaratılan API url’ lerine giden sorgulara AWS üzerinden belirli kaynaklara erişime izin verirken, diğer user/grup için üye olduktan sonra izin verdiğimiz tüm kaynaklara erişim haklarını verebiliyoruz.
AWS Cognito’nun kısaca nasıl yapılandırılacağı hakkında bilgi verecek olursak Cognito servisini açtığımızda Figure 1.1 de göreceğiniz 2 adet seçenek ile karşılaşacaksınız.
-Manage User Pools
-Manage Federated Identities
Federated Identities; az önce de bahsettiğim, kullanıcıların Facebook, Twitter, gibi 3. parti kimlik sağlayıcılarıyla giriş yaparak AWS kaynaklarına erişim sağlayan modüldür.
User Pools; Kullanıcı kontrollerini sağladığımız modüldür.
Manage User Pools diyerek açılan ekrandan Create a User Pool diyoruz ve yeni bir kullanıcı havuzu oluşturuyoruz. Burada karşımıza gelen ekrandan (Figure 5.3) havuzumuza isim vererek Step Through Settings diyerek AWS in bizi sihirbazı ile adım adım yönlendirmesini istiyoruz.
Burada son kullanıcıya nasıl oturum açması gerektiğini konfigüre ediyoruz. Kullanıcı adı ile, e-posta adresi veya telefon numarası ile kullanıcı oluşturmasını isteyebilir, büyük küçük harf duyarlılığını yönetebilir ve adres, takma ad, telefon numarası gibi standart özelliklerin gerekliliğini ayarlayabiliriz. (Standart özelliklerin tümü kullanıcı profilleri için kullanılabilir buradaki önemli nokta yazdığınız uygulamanın kayıt işleminde hangi bilgileri kullandığınız ya da hangi verileri işlemek istediğiniz ile alakalı olarak zorunlu alan olarak işaretlenmelidir. Figure 5.4)
NOT : Buradaki gereksinimler iyi analiz gerektirir, havuz oluşturduktan sonra gereksinim değişikliğini yapmanıza izin verilmez.
Sonraki adımda şifre, otomatik kayıt olma ve ilk oluşturulan şifrenin geçerlilik süresi Policy lerini belirliyoruz.(Figure 5.5)
Bir diğer ekranda MFA(Multi Factor Authentication) aktif edilip edilmeyeceği, kullanıcının şifre sıfırlama işlemlerini, ve kullanıcıların sahipliğini onaylamak için e-posta ya da sms olarak bir kod alması gerekip gerekmediği ayarlarını belirliyoruz ve son olarak bir Role yaratarak devam ediyoruz. (Figure 5.6)
Bu ekranımızda ise e-mail özelleştirme işlemlerini yapıyoruz. Eğer Amazonun bir diğer servisi olan SES(Simple Email Service) kullanıyor ve onaylı bir kimlik üzerinden mail gönderiyorsak buradaki ayarlarımızı buna göre yapılandırıyoruz. (Figure 5.7)
Aynı ekran üzerinde e-posta doğrulama mesajlarını ve kullanıcı davet mesajlarını özelleştiriyoruz. Onay kodu ve kullanıcı davet mesajlarının içeriklerini belirliyoruz.(Figure 5.8)
Sonraki ekranda kullanıcı cihazlarını hatırlamak isteyip istemediğimizi belirtiyoruz. Bu özelliği kullanmak için MFA’in açılması gerekir.
(Figure 5.9)
İstemcileri ayarladığımız ekranımızda (App Clients), hangi uygulama istemcilerinin bu kullanıcı havuzunda erişime sahip olacağını belirtiyoruz. App Clients bölümünde bir ID oluşturmamız gerekiyor. Burada oluşturacağımız ID önemlidir. Çünkü uygulamalarımızda bu ID’yi kullanarak hangi Pool a bağlanacağımızı belirtiyoruz. (Figure 5.10)
Workflow trigger (İş akış tetikleyicileri) özelleştirmek istediğimiz ekranımızda Lambda işlevleriyle çeşitli özelleştirmeler yapabiliriz buradaki özellik kullanıcı yaratılmadan önce ya da kullanıcı yaratıldıktan sonra vs. gibi durumlar için belirli bir kod parçası çalıştırmak istiyorsak ilgili yerleri kullanabiliriz. (Figure 5.11)
Sizlere genel olarak AWS IAM ve Cognito hakkında bilgiler vermeye çalıştım. Umarım yararlı bir yazı olmuştur. Bir sonraki yazımızda görüşmek dileğiyle.
