Banka, projelerini birçok yükleniciye devrediyor. "Hariciler" kod yazar ve sonuçları pek uygun olmayan bir biçimde iletir. Spesifik olarak süreç şuna benziyordu: Kendileriyle birlikte işlevsel testleri geçen bir projeyi teslim ettiler ve ardından entegrasyon, yük vb. açısından bankacılık çevresinde test edildi. Testlerin başarısız olduğu sıklıkla keşfedildi. Sonra her şey harici geliştiriciye geri döndü. Tahmin edebileceğiniz gibi bu, hata düzeltmeleri için uzun teslim süreleri anlamına geliyordu.
Banka, taahhütlerden serbest bırakmaya kadar tüm boru hattını kanatları altına almanın mümkün ve gerekli olduğuna karar verdi. Böylece bankada her şey tekdüze ve üründen sorumlu ekiplerin kontrolünde oluyor. Yani, sanki dış yüklenici ofisin yan odasında bir yerde çalışıyormuş gibi. Kurumsal yığında. Bu sıradan bir devops.
Sec nereden geldi? Bankanın güvenliği, harici bir yüklenicinin ağ segmentinde nasıl çalışabileceği, birinin hangi erişime sahip olduğu, kodla nasıl ve kimin çalışacağı konusunda yüksek talepler doğurdu. Sadece IB, yüklenicilerin dışarıda çalışırken çok az sayıda bankacılık standardına uyulduğunu henüz bilmiyordu. Ve birkaç gün içinde herkesin onları gözlemlemeye başlaması gerekiyor.
Yüklenicinin ürün koduna tam erişime sahip olduğunun basit bir şekilde ortaya çıkması, onların dünyasını çoktan altüst etmişti.
İşte bu noktada sizlere anlatmak istediğim DevSecOps'un hikayesi başladı.
Banka bu durumdan ne gibi pratik sonuçlar çıkardı?
Her şeyin yanlış şekilde yapıldığına dair pek çok tartışma vardı. Geliştiriciler, güvenliğin yalnızca gelişime müdahale etmeye çalışmakla meşgul olduğunu ve bekçiler gibi düşünmeden yasaklamaya çalıştıklarını söyledi. Buna karşılık, güvenlik uzmanları şu bakış açıları arasında seçim yapmakta tereddüt etti: "Geliştiriciler devremizde güvenlik açıkları yaratır" ve "geliştiriciler güvenlik açıkları yaratmaz, bizzat kendileridir." Yeni pazar talepleri ve DevSecOps paradigmasının ortaya çıkışı olmasaydı, anlaşmazlık uzun süre devam edecekti. Bilgi güvenliği gereksinimlerini "kutudan çıktığı haliyle" dikkate alan bu süreç otomasyonunun herkesin mutlu kalmasına yardımcı olacağını açıklamak mümkündü. Kuralların anında yazılması ve oyun sırasında değişmemesi (bilgi güvenliği beklenmedik bir şeyi yasaklamayacaktır) ve geliştiricilerin bilgi güvenliğini olup biten her şeyden haberdar etmesi (bilgi güvenliğinin aniden bir şeyle karşılaşmaması) anlamındadır. . Her takım aynı zamanda nihai güvenlikten de sorumludur, bazı soyut ağabeyler değil.
- Dışarıdan çalışanların zaten koda ve bir takım iç sistemlere erişimi olduğundan, "geliştirme tamamen bankanın altyapısı üzerinde yapılmalıdır" şartının belgelerden kaldırılması muhtemelen mümkündür.
- Öte yandan olup bitenler üzerindeki kontrolümüzü güçlendirmemiz gerekiyor.
- Uzlaşma, çalışanların dışarıdaki kişilerle yakın işbirliği içinde çalıştığı işlevler arası ekiplerin oluşturulmasıydı. Bu durumda ekibin banka sunucularındaki araçlar üzerinde çalıştığından emin olmanız gerekir. Baştan sona.
Yani müteahhitlere izin verilebilir ancak onlara ayrı bölümler verilmesi gerekir. Böylece bankanın altyapısına dışarıdan bir tür enfeksiyon bulaştırmasınlar ve gereğinden fazlasını görmesinler. Böylece eylemleri günlüğe kaydedilir. Sızıntılara karşı koruma için DLP, bunların hepsi dahildi.
Prensip olarak tüm bankalar er ya da geç buna gelir. Burada alışılagelmişin dışına çıktık ve “dışarıdakilerin” çalıştığı ortamların gereksinimleri üzerinde anlaştık. Maksimum çeşitlilikte erişim kontrol araçları, güvenlik açığı kontrol araçları, devreler, montajlar ve testlerde anti-virüs analizi ortaya çıktı. Buna DevSecOps denir.
Birdenbire, DevSecOps'tan önce bankacılık güvenliğinin geliştirici tarafında olup bitenler üzerinde hiçbir kontrolü olmadığı halde, yeni paradigmada güvenliğin altyapıdaki sıradan olaylarla aynı şekilde kontrol edildiği açıkça ortaya çıktı. Ancak şimdi meclisler, kütüphanelerin kontrolü vb. konularda uyarılar var.
Geriye kalan tek şey takımları yeni modele aktarmak. Peki, altyapıyı oluşturun. Ama bunlar önemsiz şeyler, baykuş çizmeye benziyor. Aslında altyapı konusunda yardımcı olduk ve o dönemde geliştirme süreçleri değişiyordu.
Ne değişti
Bunu küçük adımlarla uygulamaya karar verdik çünkü birçok sürecin çökeceğini ve birçok "dışarıdan" herkesin denetimi altındaki yeni çalışma koşullarına dayanamayabileceğini anlamıştık.
Öncelikle işlevler arası ekipler oluşturduk ve yeni gereksinimleri dikkate alarak projeler düzenlemeyi öğrendik. Organizasyonel anlamda hangi süreçlerin olduğunu tartıştık. Sonuçta tüm sorumluların yer aldığı montaj hattının bir diyagramı ortaya çıktı.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Testi: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performans Merkezi, MF UFT, Ataccama.
- Sunum (raporlama, iletişim): Grafana, Kibana, Jira, Confluence, RocketChat.
- Operasyon (bakım, yönetim): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Servis Yöneticisi, Jira, Confluence, MS Project.
Seçilen yığın:
- Bilgi Tabanı - Atlassian Kesişimi;
- Görev izleyici - Atlassian Jira;
- Eser deposu - “Nexus”;
- Sürekli entegrasyon sistemi - “Gitlab CI”;
- Sürekli analiz sistemi - “SonarQube”;
- Uygulama güvenliği analiz sistemi - “Micro Focus Fortify”;
- İletişim sistemi - “GitLab Mattermost”;
- Konfigürasyon yönetim sistemi - “Ansible”;
- İzleme sistemi - “ELK”, “TICK Stack” (“InfluxData”).
Müteahhitleri içeriye sürüklemeye hazır bir ekip oluşturmaya başladılar. Birkaç önemli şeyin olduğunun farkına varılmıştır:
- En azından kod iletirken her şeyin birleştirilmesi gerekir. Çünkü ne kadar yüklenici varsa o kadar da kendine has özellikleri olan farklı geliştirme süreçleri vardı. Herkesi yaklaşık olarak bir taneye sığdırmak gerekiyordu, ancak seçeneklerle.
- Çok sayıda yüklenici var ve altyapının manuel olarak oluşturulması uygun değil. Herhangi bir yeni görev çok hızlı bir şekilde başlamalıdır; yani, geliştiricilerin ardışık düzenlerini yönetmek için bir dizi çözüme sahip olması için örnek neredeyse anında dağıtılmalıdır.
İlk adımı atmak için ne yapıldığını anlamak gerekiyordu. Ve oraya nasıl gideceğimizi belirlememiz gerekiyordu. Hem altyapı hem de CI/CD otomasyonunda hedef çözümün mimarisinin çizilmesine yardımcı olarak başladık. Daha sonra bu konveyörün montajına başladık. Herkes için aynı olan, aynı konveyörlerin çalışacağı bir altyapıya ihtiyacımız vardı. Banka, hesaplamalarla seçenekler sunduk, sonra neyin inşa edileceğine ve hangi fonlarla yapılacağına karar verdik.
Daha sonra devrenin oluşturulması - yazılımın kurulumu, konfigürasyon. Altyapı dağıtımı ve yönetimi için komut dosyalarının geliştirilmesi. Daha sonra konveyör desteğine geçiş geliyor.
Her şeyi pilotta test etmeye karar verdik. İlginç bir şekilde, pilot uygulama sırasında bankada ilk kez belirli bir yığın ortaya çıktı. Diğer şeylerin yanı sıra, hızlı bir lansman için pilot kapsamında çözümlerden birinin yerli tedarikçisine teklif edildi. Güvenlik onu pilotluk yaparken tanıdı ve unutulmaz bir izlenim bıraktı. Neyse ki geçiş yapmaya karar verdiğimizde altyapı katmanının yerini daha önce bankada bulunan bir Nutanix çözümü aldı. Üstelik bundan önce VDI içindi ama biz bunu altyapı hizmetleri için tekrar kullandık. Küçük hacimlerde ekonomiye uyum sağlayamadı ancak büyük hacimlerde geliştirme ve test için mükemmel bir ortam haline geldi.
Yığının geri kalanı az çok herkese tanıdık geliyor. Ansible'daki otomasyon araçları kullanıldı ve güvenlik uzmanları onlarla yakın işbirliği içinde çalıştı. Atlassin yığını projeden önce banka tarafından kullanılıyordu. Fortinet güvenlik araçları - güvenlik görevlilerinin kendileri tarafından önerildi. Test çerçevesi banka tarafından oluşturuldu, hiçbir soru sorulmadı. Arşiv sistemi soruları gündeme getirdi; alışmam gerekiyordu.
Müteahhitlere yeni bir yığın verildi. Bize bunu GitlabCI için yeniden yazmamız ve Jira'yı bankacılık segmentine taşımamız için zaman verdiler.
adım adım
1 Adım. İlk olarak yerli bir satıcının çözümünü kullandık, ürün yeni oluşturulan bir DSO ağ segmentine bağlandı. Platform, teslimat süresi, ölçeklendirme esnekliği ve tam otomasyon olanağı nedeniyle seçildi. Yapılan testler:
- Sanallaştırma platformu altyapısının (ağ, disk alt sistemi, bilgi işlem kaynakları alt sistemi) esnek ve tam otomatik yönetimi imkanı.
- Sanal makine yaşam döngüsü yönetiminin otomasyonu (şablon oluşturma, anlık görüntüler, yedeklemeler).
Platformun kurulumu ve temel konfigürasyonunun ardından ikinci aşama alt sistemlerin (DSO araçları, perakende sistemleri geliştirme ana hatları) yerleştirme noktası olarak kullanıldı. Gerekli işlem hattı setleri oluşturuldu - sanal makinelerin oluşturulması, silinmesi, değiştirilmesi, yedeklenmesi. Bu işlem hatları dağıtım sürecinin ilk aşaması olarak kullanıldı.
Sonuç, sağlanan ekipmanın bankanın performans ve hata toleransı gereksinimlerini karşılamamasıdır. Bankanın DIT'si, Nutanix yazılım paketini temel alan bir kompleks oluşturmaya karar verdi.
2 Adım. Tanımlanan yığını aldık ve tüm alt sistemler için otomatik kurulum ve konfigürasyon sonrası komut dosyaları yazdık, böylece her şey pilottan hedef devreye mümkün olan en kısa sürede aktarıldı. Tüm sistemler hataya dayanıklı bir yapılandırmada (bu yeteneğin satıcının lisanslama politikalarıyla sınırlı olmadığı durumlarda) konuşlandırıldı ve ölçümlere ve olay toplama alt sistemlerine bağlandı. IB, gereksinimlerine uygunluğu analiz etti ve yeşil ışık yaktı.
3 Adım. Tüm alt sistemlerin ve ayarlarının yeni PAC'a taşınması. Altyapı otomasyon komut dosyaları yeniden yazıldı ve DSO alt sistemlerinin geçişi tam otomatik modda tamamlandı. Fikri mülkiyet gelişiminin ana hatları, geliştirme ekiplerinin boru hatları tarafından yeniden oluşturuldu.
4 Adım. Uygulama yazılımı kurulumunun otomasyonu. Bu görevler yeni ekiplerin ekip liderleri tarafından belirlendi.
5 Adım. Sömürü.
Uzaktan erişim
Geliştirme ekipleri devreyle çalışırken maksimum esneklik talep etti ve kişisel dizüstü bilgisayarlardan uzaktan erişim gereksinimi projenin en başında gündeme getirildi. Bankanın zaten uzaktan erişimi vardı ancak geliştiriciler için uygun değildi. Gerçek şu ki şema, kullanıcının korumalı bir VDI ile olan bağlantısını kullanıyordu. Bu, işyerlerinde yalnızca posta ve ofis paketine ihtiyaç duyanlar için uygundu. Geliştiricilerin yoğun istemcilere, yüksek performansa ve çok sayıda kaynağa ihtiyacı olacak. Ve elbette, VStudio (örneğin) veya başka bir SDK ile çalışanlar için kullanıcı oturumunun kaybı kabul edilemez olduğundan statik olmaları gerekiyordu. Tüm geliştirme ekipleri için çok sayıda kalın statik VDI'nin düzenlenmesi, mevcut VDI çözümünün maliyetini büyük ölçüde artırdı.
Geliştirme segmentinin kaynaklarına doğrudan uzaktan erişim üzerinde çalışmaya karar verdik. Jira, Wiki, Gitlab, Nexus, tezgahlar oluşturma ve test etme, sanal altyapı. Güvenlik görevlileri erişimin ancak aşağıdaki şartlara bağlı olarak sağlanabileceğini talep etti:
- Bankada halihazırda mevcut olan teknolojileri kullanmak.
- Altyapı, üretken hesap nesnelerinin kayıtlarını saklayan mevcut etki alanı denetleyicilerini kullanmamalıdır.
- Erişim yalnızca belirli bir ekibin ihtiyaç duyduğu kaynaklarla sınırlı olmalıdır (böylece bir ürün ekibi başka bir ekibin kaynaklarına erişemez).
- Sistemlerde RBAC üzerinde maksimum kontrol.
Sonuç olarak bu segment için ayrı bir alan adı oluşturuldu. Bu etki alanı, hem kullanıcı kimlik bilgileri hem de altyapı olmak üzere tüm geliştirme segmenti kaynaklarını barındırıyordu. Bu alandaki kayıtların yaşam döngüsü, bankada mevcut olan IdM kullanılarak yönetilir.
Bankanın mevcut donanımı esas alınarak doğrudan uzaktan erişim düzenlendi. Erişim kontrolü, bağlamlardaki kuralların karşılık geldiği AD gruplarına bölündü (bir ürün grubu = bir kural grubu).
VM Şablon Yönetimi
Bir montaj ve test döngüsü oluşturma hızı, geliştirme birimi başkanı tarafından belirlenen ana KPI'lardan biridir, çünkü ortamı hazırlama hızı, boru hattının genel yürütme süresini doğrudan etkiler. Temel VM görüntülerini hazırlamak için iki seçenek değerlendirildi. Bunlardan ilki, minimum görüntü boyutları, tüm sistem ürünleri için varsayılan, ayarlara ilişkin banka politikalarına maksimum uyumdur. İkincisi, kurulum süresi boru hattının yürütme hızını büyük ölçüde etkileyebilecek ağır hizmet tipi bir POPPO'nun kurulu olduğu temel görüntüdür.
Geliştirme sırasında görsellerin güncel tutulması (yamalar vb.), SIEM ile entegrasyon, banka standartlarına uygun güvenlik ayarları gibi altyapı ve güvenlik gereksinimleri de dikkate alındı.
Sonuç olarak, güncel tutma maliyetini en aza indirmek için minimum görsel kullanılmasına karar verildi. Temel işletim sistemini güncellemek, her görüntüye POPPO'nun yeni sürümleri için yama uygulamaktan çok daha kolaydır.
Sonuçlara dayanarak, güncellemesi operasyon ekibi tarafından gerçekleştirilen minimum gerekli işletim sistemi setinden oluşan bir liste oluşturuldu ve boru hattındaki komut dosyaları, yazılımın güncellenmesinden ve gerekirse sürümün değiştirilmesinden tamamen sorumludur. yüklü yazılımın - gerekli etiketi boru hattına aktarmanız yeterlidir. Evet, bu, devops ürün ekibinin daha karmaşık dağıtım senaryolarına sahip olmasını gerektirir, ancak temel görüntüleri desteklemek için gereken operasyonel süreyi büyük ölçüde azaltır; aksi takdirde bakımı yüzün üzerinde temel VM görüntüsü gerektirebilir.
İnternet erişimi
Bankacılık güvenliğinin önündeki bir diğer engel de geliştirme ortamından İnternet kaynaklarına erişimdi. Ayrıca, bu erişim iki kategoriye ayrılabilir:
- Altyapı erişimi.
- Geliştirici erişimi.
Altyapı erişimi, Nexus ile harici depoların proxy'lenmesiyle düzenlendi. Yani sanal makinelerden doğrudan erişim sağlanamadı. Bu, geliştirme segmentinden dış dünyaya herhangi bir erişim sağlanmasına kategorik olarak karşı olan bilgi güvenliği ile uzlaşmaya varılmasını mümkün kıldı.
Geliştiricilerin bariz nedenlerden dolayı (yığın akışı) İnternet'e erişmeleri gerekiyordu. Yukarıda belirtildiği gibi tüm komutların devreye uzaktan erişimi olmasına rağmen, geliştiricinin IDE'deki bankadaki işyerinden ctrl+v yapamamanız her zaman uygun değildir.
IS ile başlangıçta test aşamasında erişimin beyaz listeye dayalı bir bankacılık proxy'si aracılığıyla sağlanacağı konusunda bir anlaşmaya varıldı. Projenin tamamlanmasının ardından erişim kara listeye aktarılacaktır. Projenin başlangıcında erişimin gerekli olduğu ana kaynakları ve depoları gösteren devasa erişim tabloları hazırlandı. Bu erişimleri koordine etmek oldukça zaman aldı ve bu da kara listelere mümkün olan en hızlı geçiş konusunda ısrar etmeyi mümkün kıldı.
Bulgular
Proje bir yıldan biraz daha kısa bir süre önce sona erdi. Garip bir şekilde, tüm yükleniciler zamanında yeni yığına geçtiler ve yeni otomasyon nedeniyle kimse kalmadı. IB'nin olumlu geri bildirimleri paylaşmak için acelesi yok ama şikayet de etmiyor, bundan da hoşlarına gittiği sonucunu çıkarabiliriz. Bilgi güvenliği yeniden kontrol altında hissedildiğinden ancak geliştirme süreçlerine müdahale etmediğinden çatışmalar azaldı. Ekiplere daha fazla sorumluluk verildi ve bilgi güvenliğine yönelik genel tutum daha iyi hale geldi. Banka, DevSecOps'a geçişin neredeyse kaçınılmaz olduğunu anladı ve bence bunu en nazik ve doğru şekilde yaptı.
Alexander Shubin, sistem mimarı.
Kaynak: habr.com