Birçok sunucu için SSH erişim ağ geçidi

Ansible aracılığıyla şu anda 3 devopsiyle 90'dan fazla sunucuyu yönetme. Her şey harika çalışıyor, ancak şu anda dev bir güvenlik sorunu var. Her devop, sunuculara doğrudan erişmek için kendi yerel ssh anahtarlarını kullanıyor. Her devop bir dizüstü bilgisayar kullanır ve her dizüstü bilgisayar potansiyel olarak tehlikeye atılabilir, böylece tüm prod sunucu ağını bir saldırıya kadar açabilir.

Erişimi merkezi olarak yönetmek ve böylece herhangi bir anahtar için erişimi engellemek için bir çözüm arıyorum. Anahtarların bitbucket veya github'a nasıl eklendiğinden farklı değil.

Başımın üst kısmından çözümün bir makineden, ağ geçidinden, istenen eşya sunucusuna bir tünel olacağını varsayacağım ... ağ geçidini geçerken, istek yeni bir anahtar alacak ve ürüne erişmek için kullanacaktı sunucusu. Sonuç olarak, ağ geçidine erişimi reddederek saniyeler içinde herhangi bir devop için erişimi hızlı ve verimli bir şekilde öldürebiliriz.

Bu iyi bir mantık mı? Herkes bu sorunu önlemek için zaten bir çözüm gördü mü?

Bu çok karmaşık (bir anahtarın belirli bir ürün sunucusuna erişimi olup olmadığını kontrol etme). Ağ geçidi sunucusunu, geçerli tüm anahtarları kabul eden (ancak tüm sunuculara sırayla erişimi kaldıran belirli bir anahtarın erişimini kolayca kaldırabilen) atlama ana bilgisayarı olarak kullanın ve yalnızca her bir sunucuya yalnızca izin verilen anahtarları ekleyin. Bundan sonra, her sunucunun SSH bağlantı noktasına yalnızca atlama ana bilgisayarı üzerinden erişebildiğinizden emin olun.

Standart yaklaşım budur.

Bu bir geliştirme / test ortamı olmadıkça mühendisler doğrudan dizüstü bilgisayarlarından sorumlu çalışmamalıdır.

Bunun yerine, çalışma kitaplarını git'ten çeken merkezi bir sunucunuz olsun. Bu, ek kontrollere izin verir (dört göz, kod incelemesi).

Erişimi daha da kısıtlamak için bunu bir bastion veya atlama ana bilgisayarı ile birleştirin.

Netflix kurulumunuzu gerçekleştirdi ve bu duruma yardımcı olmak için bazı ücretsiz yazılımlar yayınladı.

Bu videoya https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access veya bu sunumu https://speakerdeck.com/rlewis/how-netflix-gives- adresinde bulabilirsiniz. tüm-mühendisleri-ssh-örneklerine erişim- çekirdek noktası ile üretimde :

Özünde mühendislerin kimliğini doğrulamak için TOA kullanan SSH kalesi mimarimizi gözden geçireceğiz ve ardından bir örneğe kalenin SSH kimlik doğrulaması için kısa ömürlü sertifikalarla kullanıcı kimlik bilgileri başına yayınlayacağız. Bu kısa ömürlü kimlik bilgileri kaybolma riskini azaltır. Bu yaklaşımın, erişim vermeden önce mühendisleri yavaşlatmak yerine, olaydan sonra nasıl denetlememizi ve otomatik olarak uyarmamızı sağlayacağımızı ele alacağız.

Yazılımlarına buradan ulaşabilirsiniz: https://github.com/Netflix/bless

Tüm çözümlerini uygulamasanız bile bazı ilginç şeyler alır:

• sadece anahtarlar yerine SSH sertifikaları kullanırlar; sertifikaya çok daha fazla meta veri koyabilir, böylece gereksinimler başına çok fazla kısıtlama sağlayabilir ve daha basit denetimlere izin verebilirsiniz
• çok kısa süreli (5 dakika gibi) sertifika geçerliliği kullanma (SSH oturumları sertifikanın süresi dolduktan sonra bile açık kalır)
• komut dosyası oluşturmayı zorlaştırmak için 2FA kullanmak ve geliştiricileri diğer çözümleri bulmaya zorlamak
• belirli bir alt modül, altyapılarının dışında ve çalıştığı bulut tarafından sunulan güvenlik mekanizmaları ile düzgün bir şekilde güvence altına alınmış, her geliştiricinin herhangi bir ana bilgisayara erişebilmesi için sertifika oluşturma işlemini dinamik olarak gerçekleştirir

OneIdentity (eski Balabit) SPS , bu senaryoda ihtiyacınız olan şeydir. Bu cihazla, temelde herhangi bir makinedeki kullanıcı kimliklerini yönetebilir, kullanıcı davranışını izleyebilir, izleyebilir ve uyarabilir ve daha sonraki incelemeler için kullanıcıların ne yaptığını endeksleyebilirsiniz.

Benim önerim, kullanıcı makinelerinden SSH erişimine izin vermemek.

Bunun yerine yapmalısın

1. Oyun kitaplarını Git'te barındırın.
2. "Erişim sunucusu" nu Jenkins sunucusuna dönüştürün.
3. Grant, kullanıcı kullanıcılarına yalnızca Jenkins erişimine ihtiyaç duydu.
4. HTTP üzerinden iş kurmak için Jenkins üzerinde Ansible oyunları yürütün.
5. Ek bir güvenlik önlemi olarak, gerekirse Jenkins CLI'yı devre dışı bırakın.

Örnek yürütme modeli,

1. Jenkins Ansible eklentisi: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

VEYA

2. Klasik kabuk -güzel iş türü. Git adımlarını da içeren derleme adımlarınızı manuel olarak ekleyin.

Sunucu kaynakları ile sınırlıysanız, aynı Jenkins sunucusu Git'i (scm-manager) da barındırabilir, ancak geliştirici makinesinden birine virüs bulaşmışsa ek bir güvenlik riski vardır. Jenkins sunucusunu internetten ayırarak bunu hafifletebilir ve Ansible bağımlılıklarını yerel olarak çözebilirsiniz.