İlk ders: Sırlarınızı orta gönderimde sızdırmazsınız

Uygulamanızda sır saklamanın en iyi yolu uygulamanızda sır saklamak değildir

Feragatname: Bu makalede açıklanan yöntem ağırlıklı olarak AWS'ye dayanmaktadır. Olduğu söyleniyor, kavram hala diğer sağlayıcılar için geçerli olabilir…

İnternette bir uygulama geliştirdiyseniz, sunucunuzda sır saklama (veritabanı kimlik bilgileri, api anahtarları, vb.) İle karşılaştınız.

Tarihsel olarak, geliştiriciler bunu başarmanın birkaç yolunu bulmuşlardır. Her biri belirli bir güvenlik ve rahatlık seviyesine sahiptir. Onlardan geçeceğim, böylece nereden geldiğimize dair bir fikir edinebilirsiniz.

Sırları kodunuzda saklamak

# settings / example_settings.py
STRIPE_API_KEY = '3ef8-843a-49dc-a34d' # Kimseye söyleme! plz?

Bu açıkçası en uygun yöntem. API anahtarınızı kodunuza sabit olarak yazıyorsunuz, sonra kaynak kontrolünüze itiyorsunuz ve voilà!

Ancak, aynı zamanda en az güvenli yöntemdir. Sadece her geliştiricinin bilgisayarına (veya harici sürücülerine), kaynak kontrol sağlayıcınızın deposuna, CI sağlayıcınızın sunucusuna vb. Yayılmasına izin verdiniz. Bu, bu sırrın sızabileceği riskini büyük ölçüde artırıyor.

Çevrede sır saklamak

stripe_api_key = os.environ ["STRIPE_API_KEY"]

Bu oldukça sık kullandığım bir şey. Bu ortam değişkenlerini her sunucuda el ile ayarlamanız veya önceki yöntemden biraz daha az kullanışlı olan sizin için işlemek üzere bir tür orkestratör kullanmanız gerekir. Buna rağmen, yalnızca bazı güvenilir kişilerin buna erişebilmesi avantajına sahiptir.

Hala bazı sorunlar var: basit bir yanlış yapılandırma (bir üretim sunucusunu hata ayıklama modunda çalıştırmak gibi) veya bir güvenlik hatası, tüm ortam değişkenlerinin sızmasına neden olabilir.

Sırları veritabanında saklamak

Bu konuyu kısaca ele alacağım: veritabanı kimlik bilgilerinizi dışarıda bir yerde bulundurmanız gerekecek, bu yüzden sırlarınızı buraya koyma amacını ortadan kaldırmanız gerekecek. Ayrıca, tüm servislerinizin API anahtarlarının günlük olarak yedeklenmesi de bir noktada sızıntı riskini artırır.

Bir sır senkronizasyon servisi kullanma

API anahtarlarınızla ve sizin için diğer sırlarla ilgilenmeyi sağlayan SaaS vardır. Onları güvende tutar ve gerektiğinde hizmetlerinden sorgulamanıza izin verir. Önceki yöntemle hala aynı sorunla karşı karşıyayız: Tüm API anahtarlarınızı almak için çok gizli bir API anahtarına ihtiyacınız olacak.

Sırları kodunuzda saklayın… ancak şifreli

İlk yöntemin modern bir versiyonu, kodunuzdaki sırları şifrelemek, böylece değerlerini kaynak kontrolünüze, diğer geliştiricilere vb. Maruz bırakmamaktır. Ancak, bu sırların şifresini çözmek için, sunucunun hala bir anahtarı yönetmesi gerekir. Bu, diğer tüm sırları açan büyük bir sırrı dağıtma ve sürdürme sorununa geri dönüyor.

Neden güvensiz?

Bu yöntemlerin hepsi aynı özelliği paylaşır; onlar hala sunucunuzda sır bulundurmayı içerir ve bunlar sızıntı yapabilir ya da çalınabilir

En kötü durum senaryosu

Aşağıdaki senaryoyu hayal edin. Bir saldırgan, Apache'deki bir güvenlik açığını kullanarak sunucunuza girdi. Daha sonra yapılandırma dosyanızdaki, kodunuzdaki, ortamdaki veritabanı kimlik bilgilerini ve API anahtarlarını aramaya başlar. Sırlarınız bir şekilde yeterince gizli / şifreli ise, saldırgan hiçbir şey bulamaz. Fakat bu orada duracağı anlamına gelmez. LiME gibi bir şey kullanarak, bilgisayar korsanı hala bu sırları açığa çıkarmak için sunucunun bellek dökümüne göz atabilirdi.

Daha iyisini yapabiliriz

Tanıtımı:

Proxy ™ olarak bir IAM onaylı API Ağ Geçidi kullanarak kimlik bilgileri gerektirmeyen hizmet erişimi

(Akılda kalıcı isimler bulmakta berbatım ve bu gerçekten ticari markalı değil)

genel bakış

Özetle, EC2 örneğimizin örnek rolünü, bir API Ağ Geçidine güvenli bir çağrı yapmak için kullanıyoruz; bu, istenen kimlik bilgilerini ekleyerek isteği değiştirdikten sonra istenen servise iletir. Ew! Tek bir cümle için bu kadar çok bilgi var.

Bir resmin 1000 kelimeye bedel olduğunu söylüyorlar. MEYDAN OKUMA KABUL EDİLDİ

Hala kayıp? Bunu parçalayalım

Öncelikle, bunun çalışması için EC2 örneklerinin (veya ECS Containers ve Lambdas) IAM rollerini kullanan diğer AWS kaynaklarına çağrı yapmak için doğal yolunu kullanmamız gerekir.

İkincisi, API Gateway'de bir Rest API kaynağı oluşturmamız gerekiyor. Gövde, başlıklar ve sorgu parametrelerinin geçilebilmesi için uygulanması gereken bazı özel yapılandırmalar vardır. Ek olarak, talebi değiştirmemiz gerekir, böylece hedeflenen servis kimlik bilgilerini enjekte edebiliriz. Son olarak, gizli silahı aktif hale getirmeliyiz: IAM bazlı yetkilendirme.

Üçüncü ve son adım, istenen proxy servislerine çağrı göndermeden önce URL'yi imzalamaktan ibarettir.

¿Que?

Az önce bahsettiğim teknolojilere çok aşina olmayanlar ve bunların ne hakkında olduğundan hala emin değilseniz, burada bir IAM onaylı API Ağ Geçidi'ni proxy ™ olarak kullanarak, Kimlik Bilgisi içermeyen hizmet erişimini kullanmadan önce ve sonra bir karşılaştırma yaptık:

Bu gösteri için iyi bilinen GitHub API ve Postman'ı kullanacağım:

Önce (GitHub'a doğrudan arama):

Sonra (Çağrı, API Ağ Geçidi üzerinden proxy'leri)

Dediğini duyabiliyorum zaten:

Bize bunun kimlik bilgisi olmadığını söylemiştin ve bir erişim anahtarı, bir gizli anahtar ve bir jeton görüyorum !!!

Çünkü dizüstü bilgisayarımın gizli silahı yok. Bunu bir EC2 örneğinde çalıştırdığınızda ve çalıştırdığınızda, bu geçici güvenlik bilgileri otomatik olarak örnek meta verilerinden alınır. Geçici kimlik bilgileri kavramı sizin için yeniyse, işte size belgelerden bir alıntı (benimki vurgusu):

[…] Örneği üzerindeki bir uygulamaya, rolle ilişkili güvenlik kimlik bilgileri yoluyla rol için tanımladığınız eylemler ve kaynaklar için izin verilir. Bu güvenlik bilgileri geçicidir ve bunları otomatik olarak döndürürüz. Eski kimlik bilgilerinin sona ermesinden en az beş dakika önce yeni kimlik bilgileri kullanılabilir hale getiririz.

Bu nedenle, adil olmak gerekirse, bu yöntemin daha kesin bir açıklaması, uzun vadeli kimlik bilgileri kullanılmadan bir proxy olarak bir IAM onaylı API Ağ Geçidi kullanan Hizmet erişimi olacaktır. Bununla birlikte, “IAM yoluyla sınırlandırılmış proxy servislerine yapılan çağrıları imzalamak için kullanılan kısa vadeli geçici kimlik bilgilerinin” saldırganlar için sıradan API anahtarlarından ve diğer uzun vadeli sırlardan daha az çekici olduğunu kabul edebiliriz.

Bu güvenlik açısından büyük bir yükseltmedir

Önemli güvenlik geliştirmeleri:

  • Geçici kimlik bilgileri asla geliştiriciler tarafından ele alınmamalıdır
  • Programlı olarak sorgulanırlar, bu nedenle bir yapılandırma dosyasına yazmaları gerekmez.
  • Sızan veya çalınmışsa, bu geçici kimlik bilgileri en fazla bir saat çalışacak
  • Tüm istekler denetim için CloudWatch'ta oturum açabilir
  • Bir IAM politikası kullanarak hedeflenen API'yi kısıtlayabilirsiniz.

Son madde işareti, daha ince taneli izin modeline sahip olmayan GitHub gibi bir API ile çalışırken özellikle kullanışlıdır. Aşağıdaki IAM politikasını kullanarak, API'mı yalnızca / repos / PokaInc / test-github-api / issues endpoint öğesinde GET yöntemine izin verecek şekilde kısıtlayabilirim.

{
    "Sürüm": "2012-10-17",
    "Beyan": [
        {
            "Aksiyon": [
                "Yürütme-api: Çağır"
            ],
            "Kaynak": [
                "Arn: aws: yürütmek-api: Bize-doğu-1: 123456789010: w974f1rs6e / dev / GET / repo / PokaInc / test github-api / sorunlar"
            ],
            "Efekt": "İzin Ver"
        }
    ]
}

Fakat bekleyin, dahası var!

API ağ geçidi proxy kullanmanın diğer yararları

  • Kullanım istatistikleri. Bu, trendleri tanımlamak ve üçüncü taraf hizmetlerden fiyat sınırlamasını önlemek için faydalı olabilir.
  • Kerestecilik. Etkinleştirildiğinde, menşei ve kullanılan parametreler de dahil olmak üzere her isteğin ayrıntılı günlüklerini alabilirsiniz.
  • Caching. Gecikme veya sınırlayıcı sorunlar mı yaşıyorsunuz? Üç satır CloudFormation kodu ile proxy'nize bir önbellek arka ucu ekleyebilirsiniz.
  • Yerel gelişim Yerel olarak bir IAM kullanıcısı kullanan geliştiriciler, bilgisayarlarında sabit kodlanmış kimlik bilgilerine güvenmek yerine proxy hizmetlerine doğrudan erişebilir.

Bu noktada, fikri sattığınızı ve kendiniz için yöntemi denemek istediğinizi varsayacağım.

Kod

Burada Poka'da, CloudFormation afi · cn · nados ’olduğunu göz önüne alarak GitHub'da mevcut olan bir konsept kanıtı şablonu hazırladım.

Sağlama

Proxy oluşturmak için README.md'deki talimatları izleyin.

Proxy'yi kullanma

Bu ayrıca benioku metninde de açıklanmıştır, ancak onu buraya yerleştireceğim, böylece sizi kara büyü olmadığına ikna edebiliyorum.

Bu kod bloğunu gözden geçirelim:

AWSRequestsAuth döndür
      [...]
      ** boto_utils.get_credentials ()
)

Burası genellikle kodlanmış kimlik bilgilerini, bir yapılandırma dosyasına erişimi veya çevreye bir sorguyu göreceğimiz yerdi. Bunun yerine, bu yöntem geçici anahtarlar için meta veri hizmetini ister. EC2 örneği rolünün yeterli izni varsa, çağrı GitHub'a gider, aksi takdirde API Ağ Geçidi bunu reddeder.

Sonuç

Umarım bu gönderi, uygulama sunucularındaki kötü güvenlikli sırların bilincinin artırılmasına ve API Ağ Geçidi'nin bir proxy olarak kullanılmasının size ek güvenlikten nasıl fayda sağlayacağına yardımcı olmuştur.

Uyarılar (ve bunların geçici çözümleri)

  • İnternete maruz kalmayan bir iç servis proxy'si yapmak istersem ne olur?

Açıklama kendi özel blog yazısı olabilir. Ancak uzun lafın kısası, API Ağ Geçidi proxy'nizin hedefi olarak bir VPC Etkin AWS Lambdası sağlayabilirsiniz. Lambda başlıkları, sorgu parametrelerini ve gövdeyi dahili servise iletmek, yanıtı toplamak ve API Ağ Geçidi'ne geri döndürmek zorunda kalacaktır.

  • Bu, REST API'leri ile harika çalışıyor ancak ilişkisel veritabanları veya önbellek sunucuları gibi TCP hizmetleri ne durumda?

Yine, bu tam bir blog yazısı hak ediyor. Özetle, istenen hizmetler için anında kimlik bilgileri oluşturacak bir mikro hizmet (erişilebilir, tahmin edebileceğiniz bir IAM onaylı API Ağ Geçidi) oluşturabiliriz. Örnek için: mikro hizmet PostgreSQL kimlik bilgileri isteniyorsa, rastgele oluşturulmuş bir parola ile bir CREATE ROLE komutu verebilir. Ek olarak, rol VALID UNTIL özelliğini kullanarak yaşama zamanına sahip olabilir.

Alternatifler

Üretim iş yükünüzü AWS’de çalıştırmıyor musunuz? Bu yöntem sizin için çalışamaz mı? Orada sır yönetimi ile baş etmene yardım edebilecek başka araçlar var.

  • http://engineering.nike.com/cerberus/
  • https://www.vaultproject.io/
  • https://docs.docker.com/engine/swarm/secrets/

Bu makale için referanslar:

http://blog.arkency.com/2017/07/how-to-safely-store-api-keys-in-rails-apps/
https://blog.rackspace.com/securing-application-secrets-with-ec2-parameter-store
https://www.envkey.com/
https://www.hashicorp.com/blog/Vault-announcement/
https://docs.docker.com/engine/swarm/secrets/
http://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html
http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html

Düzeltmeler için Tea Rudolf, Etienne Talbot, Simon-Pierre Gingras, Maxime Leblanc ve Marilou Simard-Baril'e teşekkür ederim (Evet, ingilizcemi incelemesi için o kadar çok insana ihtiyacım var) ve resimler için Julie Dorion-Bélanger'a teşekkürler.

Bu yayınla ilgili sorularınız / önerileriniz mi var? Aşağıya bir yorum yazın, yanıtlamak için elimden geleni yapacağım.