AWS S3 Grupları İçinde Erişim Hakları Düzenlemesini Otomatikleştirme

Yıllar önce, büyük dosya sistemlerine sahip şirket içi Unix sunucuları söz konusu olduğunda, şirketler, farklı kişiler için farklı klasörlere erişim haklarını yönetmek için kapsamlı klasör yönetimi kuralları ve stratejileri oluşturuyordu.

Genellikle bir kuruluşun platformu tamamen farklı ilgi alanlarına, gizlilik düzeyi kısıtlamalarına veya içerik tanımlarına sahip farklı kullanıcı gruplarına hizmet eder. Küresel kuruluşlar söz konusu olduğunda, bu, içeriğin konuma göre, yani temel olarak farklı ülkelere ait kullanıcılar arasında ayrılması anlamına bile gelebilir.

Diğer tipik örnekler şunları içerebilir:

• geliştirme, test ve üretim ortamları arasında veri ayrımı
• geniş bir kitlenin erişemeyeceği satış içeriği
• başka bir bölgeden görülemeyen veya erişilemeyen ülkeye özgü yasal içerik
• "liderlik verilerinin" yalnızca sınırlı bir grup insana vb. sağlanacağı projeyle ilgili içerik.

Bu tür örneklerin potansiyel olarak sonsuz bir listesi var. Buradaki nokta, platformun erişim sağladığı tüm kullanıcılar arasında dosyalara ve verilere erişim haklarını düzenlemek için her zaman bir tür ihtiyaç vardır.

Şirket içi çözümler söz konusu olduğunda, bu rutin bir görevdi. Dosya sisteminin yöneticisi sadece bazı kurallar belirledi, tercih edilen bir araç kullandı ve ardından insanlar kullanıcı gruplarına, kullanıcı grupları ise erişebilecekleri klasörlerin veya bağlama noktalarının bir listesine eşlendi. Yol boyunca, erişim düzeyi salt okunur veya okuma ve yazma erişimi olarak tanımlandı.

Şimdi AWS bulut platformlarına bakıldığında, insanların içerik erişim kısıtlamaları için benzer gereksinimlere sahip olmasını beklemek açıktır. Ancak bu sorunun çözümü artık farklı olmalı. Dosyalar artık Unix sunucularında değil, bulutta direniyor (ve potansiyel olarak yalnızca tüm kuruluş tarafından değil, hatta tüm dünya tarafından erişilebilir) ve içerik klasörlerde değil, S3 klasörlerinde depolanıyor.

Aşağıda açıklanan, bu soruna yaklaşmak için bir alternatiftir. Somut bir proje için bu tür çözümleri tasarlarken edindiğim gerçek dünya deneyimi üzerine inşa edilmiştir.

Basit Ama Büyük ölçüde Manuel Yaklaşım

Herhangi bir otomasyon olmadan bu sorunu çözmenin bir yolu nispeten basit ve kolaydır:

• Her farklı insan grubu için yeni bir grup oluşturun.
• S3 klasörüne yalnızca bu belirli grubun erişebilmesi için klasöre erişim hakları atayın.

Gereksinim çok basit ve hızlı bir çözümle gitmekse, bu kesinlikle mümkündür. Bununla birlikte, bilinmesi gereken bazı sınırlar vardır.

Varsayılan olarak, bir AWS hesabı altında en fazla 100 S3 klasörü oluşturulabilir. AWS biletine bir hizmet limiti artışı gönderilerek bu limit 1000'e kadar uzatılabilir. Bu sınırlar, sizin özel uygulama durumunuz için endişelenecek bir şey değilse, o zaman farklı etki alanı kullanıcılarınızın her birinin ayrı bir S3 klasöründe çalışmasına izin verebilir ve onu bir gün arayabilirsiniz.

İşlevler arası sorumluluklara sahip bazı insan grupları varsa veya aynı anda daha fazla alanın içeriğine erişmesi gereken bazı kişiler varsa sorunlar ortaya çıkabilir. Örneğin:

• Birkaç farklı alan, bölge vb. için veri içeriğini değerlendiren veri analistleri.
• Test ekibi, farklı geliştirme ekiplerine hizmet veren hizmetleri paylaştı.
• Aynı bölge içindeki farklı ülkelerde gösterge panosu analizi oluşturması gereken kullanıcıları raporlama.

Tahmin edebileceğiniz gibi, bu liste yine hayal edebileceğiniz kadar büyüyebilir ve kuruluşların ihtiyaçları her türlü kullanım senaryosunu üretebilir.

Bu liste ne kadar karmaşık hale gelirse, tüm bu farklı gruplara kuruluştaki farklı S3 bölümlerine farklı erişim hakları vermek için daha karmaşık erişim hakları düzenlemesine ihtiyaç duyulacaktır. Gerekli ek araçlar olacaktır ve hatta özel bir kaynağın (yönetici) erişim hakları listelerini tutması ve herhangi bir değişiklik talep edildiğinde güncellemesi gerekecektir (bu, özellikle kuruluş büyükse çok sık olacaktır).

Öyleyse, aynı şeyi daha organize ve otomatik bir şekilde nasıl başarabiliriz?

Paketler İçin Etiketleri Tanıtın

Etki alanı başına grup yaklaşımı işe yaramazsa, başka herhangi bir çözüm daha fazla kullanıcı grubu için paylaşılan gruplarla sonuçlanacaktır. Bu gibi durumlarda, dinamik olarak değiştirilmesi veya güncellenmesi kolay bazı alanlarda erişim hakları atama mantığının tamamını oluşturmak gerekir.

Bunu başarmanın yollarından biri, S3 klasörlerinde Etiketler kullanmaktır. Etiketlerin her durumda kullanılması önerilir (daha kolay faturalandırma kategorizasyonu sağlamaktan başka bir şey değilse). Ancak etiket, herhangi bir grup için gelecekte herhangi bir zamanda değiştirilebilir.

Tüm mantık, kova etiketlerine dayalı olarak oluşturulmuşsa ve geri kalanı etiket değerlerine bağlı yapılandırmaya sahipse, sadece etiket değerlerini güncelleyerek kovanın amacını yeniden tanımlayabildiğinden, dinamik özellik sağlanır.

Bunun çalışması için ne tür etiketler kullanılır?

Bu, somut kullanım durumunuza bağlıdır. Örneğin:

• Ortam türüne göre bölmeleri ayırmak gerekebilir. Dolayısıyla, bu durumda, etiket adlarından biri “ENV” gibi bir şey olmalı ve olası değerler “DEV”, “TEST”, “PROD” vb.
• Belki takımı ülkeye göre ayırmak istersiniz. Bu durumda, başka bir etiket “COUNTRY” olur ve bir ülke adına değer verir.
• Ya da iş analistleri, veri ambarı kullanıcıları, veri bilimcileri gibi kullanıcıları ait oldukları işlevsel departmana göre ayırmak isteyebilirsiniz. Böylece, "USER_TYPE" adında ve ilgili değerde bir etiket oluşturursunuz.
• Başka bir seçenek de, belirli kullanıcı grupları için kullanmaları gereken sabit bir klasör yapısını açıkça tanımlamak isteyebilirsiniz (kendi klasör karmaşasını yaratmamak ve zamanla orada kaybolmamak için). Bunu, “data/import”, “data/processed”, “data/error” gibi birkaç çalışma dizini belirtebileceğiniz etiketlerle tekrar yapabilirsiniz.

İdeal olarak, etiketleri mantıksal olarak birleştirilebilecek ve kova üzerinde bütün bir klasör yapısı oluşturacak şekilde tanımlamak istersiniz.

Örneğin, çeşitli ülkelerden farklı türde kullanıcılar için, kullanmaları beklenen önceden tanımlanmış içe aktarma klasörleriyle özel bir klasör yapısı oluşturmak için yukarıdaki örneklerden aşağıdaki etiketleri birleştirebilirsiniz:

• /<ENV>/<USER_TYPE>/<COUNTRY>/<YÜKLE>

Yalnızca <ENV> değerini değiştirerek, etiketin amacını yeniden tanımlayabilirsiniz (test ortamı ekosistemine, dev, prod, vb. atanıp atanmayacağını)

Bu, birçok farklı kullanıcı için aynı kovanın kullanılmasını sağlayacaktır. Paketler, klasörleri açıkça desteklemez, ancak "etiketleri" destekler. Bu etiketler sonuçta alt klasörler gibi çalışır çünkü kullanıcıların verilerine ulaşmak için bir dizi etiketten geçmesi gerekir (tıpkı alt klasörlerde olduğu gibi).

İçeride Dinamik İlkeler ve Harita Kovası Etiketleri Oluşturun

Etiketleri kullanılabilir bir biçimde tanımladıktan sonraki adım, etiketleri kullanacak S3 kova politikaları oluşturmaktır.

Politikalar etiket adlarını kullanıyorsa, "dinamik politikalar" adı verilen bir şey yaratıyorsunuz demektir. Bu temel olarak, politikanızın form veya yer tutucularda atıfta bulunduğu farklı etiket değerlerine sahip gruplar için farklı davranacağı anlamına gelir.

Bu adım, açıkça dinamik ilkelerin bazı özel kodlamalarını içerir, ancak süreç boyunca size yol gösterecek olan Amazon AWS ilke düzenleyici aracını kullanarak bu adımı basitleştirebilirsiniz.

Politikanın kendisinde, kovaya uygulanacak somut erişim haklarını ve bu hakların erişim düzeyini (okuma, yazma) kodlamak isteyeceksiniz. Mantık, kovalardaki etiketleri okuyacak ve kovadaki klasör yapısını oluşturacaktır (etiketlere dayalı olarak etiketler oluşturma). Etiketlerin somut değerlerine göre alt klasörler oluşturulacak ve satır boyunca gerekli erişim hakları atanacaktır.

Böyle dinamik bir politikanın güzel yanı, yalnızca bir dinamik politika oluşturup ardından aynı dinamik politikayı birçok klasöre atayabilmenizdir. Bu politika, farklı etiket değerlerine sahip kovalar için farklı davranacaktır, ancak bu tür etiket değerlerine sahip bir kova için beklentinizle her zaman uyumlu olacaktır.

Bu, erişim hakları atamalarını çok sayıda klasör için organize, merkezi bir şekilde yönetmenin gerçekten etkili bir yoludur; burada, her bölümün önceden üzerinde anlaşmaya varılan ve kullanıcılarınız tarafından kullanılacak bazı şablon yapılarını izlemesi beklenir. tüm organizasyon.

Yeni Varlıkların Katılımını Otomatikleştirin

Dinamik politikalar tanımladıktan ve bunları mevcut klasörlere atadıktan sonra, kullanıcılar, farklı gruplardan kullanıcıların sahip olmadıkları bir klasör yapısı altında bulunan içeriğe (aynı klasörde depolanan) erişmeme riski olmadan aynı klasörleri kullanmaya başlayabilirler. erişim.

Ayrıca, daha geniş erişime sahip bazı kullanıcı grupları için, hepsi aynı klasörde depolanacağı için verilere ulaşmak kolay olacaktır.

Son adım, yeni kullanıcıların, yeni grupların ve hatta yeni etiketlerin katılımını olabildiğince basit hale getirmektir. Bu, başka bir özel kodlamaya yol açar, ancak, alışma sürecinizin basit, anlaşılır algoritma mantığıyla özetlenebilecek bazı çok net kurallara sahip olduğunu varsayarsak, aşırı derecede karmaşık olması gerekmez (en azından bu şekilde kanıtlayabilirsiniz) sürecin bir mantığı vardır ve aşırı derecede kaotik bir şekilde yapılmaz).

Bu, yeni bir varlığı platforma başarılı bir şekilde dahil etmek için gereken parametrelerle AWS CLI komutu tarafından yürütülebilir bir komut dosyası oluşturmak kadar basit olabilir. Hatta belirli bir sırayla çalıştırılabilen bir dizi CLI betiği bile olabilir, örneğin:

• create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
• create_new_tag(<bucket_id>,<tag_name>,<tag_value>)
• update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
• create_user_group(<user_type>,<ülke>,<env>)
• vesaire.

Demek istediğimi anladın.

Profesyonel Bir İpucu

İsterseniz, yukarıdakilere ek olarak kolayca uygulanabilen bir Pro İpucu vardır.

Dinamik politikalar, yalnızca klasör konumlarına erişim hakları atamak için değil, aynı zamanda klasörler ve kullanıcı grupları için otomatik olarak hizmet hakları atamak için de kullanılabilir!

Tek yapılması gereken, paketlerdeki etiket listesini genişletmek ve ardından somut kullanıcı grupları için belirli hizmetleri kullanmak üzere dinamik ilke erişim hakları eklemektir.

Örneğin, belirli veritabanı kümesi sunucusuna da erişmesi gereken bazı kullanıcı grupları olabilir. Bu, hiç şüphesiz kova görevlerinden yararlanan dinamik politikalarla elde edilebilir, özellikle de hizmetlere erişim rol tabanlı bir yaklaşımla yönlendiriliyorsa. Dinamik ilke koduna, veritabanı kümesi belirtimine ilişkin etiketleri işleyecek ve ilke erişim ayrıcalıklarını söz konusu DB kümesine ve kullanıcı grubuna doğrudan atayacak bir parça eklemeniz yeterlidir.

Bu şekilde, yeni bir kullanıcı grubunun katılımı, yalnızca bu tek dinamik politika tarafından yürütülebilir olacaktır. Ayrıca, dinamik olduğu için, aynı ilke birçok farklı kullanıcı grubunu işe almak için yeniden kullanılabilir (aynı şablonu izlemesi beklenir, ancak aynı hizmetleri izlemesi gerekmez).

Bölümleri ve verileri yönetmek için bu AWS S3 Komutlarına da göz atabilirsiniz.