Dört göz prensibinin olası uygulamaları (veya örnekleri) nelerdir?

Michael Grünewald kısa süre önce bu yorumu yayınladı :

Bahsetmediğiniz çok önemli bir yöntem, finansmanda - düzenleyici bir zorunluluk olarak veya güvenlik görevlisi olarak kullanılan “dört göz ilkesi” dir. Yazılım endüstrisinde, örneğin kod incelemeleri gibi çeşitli şekillerde uygulanır ancak canlı sistemleri etkileyen komutları doğrulamak için de kullanılabilir.

Yanlış olursam düzelt beni, ama "dört göz ilkesinin" en azından 2 kişinin (ve / veya otomatik işlemlerin) önceki nimetlerini vermesinden sonra "gerçekleşmesi onaylanan" bir şeyle ilgili olduğu öğrenildi. Veya hakkında (biraz düzeltilmiş) ifadeleri kullanmak "iki- (wo) adam kuralına" dan Vikipedi :

İki kişilik kural, özellikle kritik malzeme veya işlemler için yüksek güvenlik seviyesine ulaşmak için tasarlanmış bir kontrol mekanizmasıdır. Bu kural uyarınca, tüm erişim ve eylemler her zaman iki yetkili kişinin varlığını gerektirir.

Düzenleyici yükümlülükler burada kesinlikle konu dışıdır, ancak “güvenli koruma” bağlamında, muhtemelen kullanılan herhangi bir platform / işletim sistemi / donanım için geçerli olabilecek bu dört göz ilkesinin olası kavramsal uygulamaları nelerdir?

Koddaki uygulamalardan biri GitHub tarafından popüler olan Çekme İsteği modelidir (PR).

Bunun arkasındaki ana neden, yalnızca küçük bir ürün koruyucular grubunun kodu serbest bırakma dalında birleştirmesine izin verilmesidir. Her yeni özellik / hata düzeltme yeni bir dalda gerçekleşecek ve bir kez yapılan çekme isteği olarak tanımlanacaktır.

Bu, gerçek serbest bırakma (master) kodundan PR kodunu otomatik olarak PR ile test etmeyi sağlar (Travis aslında kamu projesi için en popüler olanıdır) ve kod kalitesi hakkında ilk beslemeyi geri verir. Travis CI (örneğin), asıl masterin sonucuna, çekme isteğinden gelen kodla birleştirilerek çalıştırılabilir; bu nedenle, birleştirme imkansızsa veya travisci.yml'de tanımlanan komutlar sıfır olmayan bir çıkış döndürdüğünde başarısız olur kod

Otomatik testler geçtikten sonra, 4 göz prensibi için, en az 1 kişinin (PR yazarı olmayan) 4 göze bakması için zorunlu olarak birleştirilmeden önce değişikliği gözden geçirmesi ve onaylaması gerekmektedir. değiştirir.

Hakemlerin nisabı karşılandıktan sonra otomatik olarak birleştirme veya hala bir bakıcı tarafından elle birleştirmeye ihtiyaç duyan çok çeşitli seçenekler vardır.

Gözden geçirme ve birleştirme izinleri ayrılabilir ve bu da daha çok insana birleştirme işlemini yapabilecek kişileri kısıtlama olasılığını koruyarak birleştirme statüsünde "oy kullanma" hakkı verir.

Kod Yorumları

Bu, en az 1 kişinin birisinin yazdığı koda bakmasıyla ilgilidir, örneğin, aşağıdaki gibi önceden tanımlanmış bazı kriterleri karşılayıp karşılamadığını

• Kodlama standartları (girintiler, vb.)
• Satır içi belgeler.
• Kodun bakımı.
• Hata işleme.
• Tamlık (örneğin if/then/elseveya case/whenyapılar olası tüm durumları kapsar).

Bazı hedef ortamları güncelleme onayları

Bu, bazı hedef ortamları güncellemesine izin verilmeden önce bazı kişilerden ve / veya otomatik sistemden en az 2 onay almakla ilgilidir (bunlar canlı olabilir veya bazı ana dosyalar / temel kitaplıkları gibi olabilir). Bazı örnekler:

• Kaynak bileşenlerini çalıştırılabilir bileşenlerde dönüştürürken (inşa ederken) yalnızca sınırlı bir uyarı grubuna izin verilir.
• Bazı otomatik testler herhangi bir problem olmadan tamamlanmış olmalıdır.
• Bazı insanlar ön onaylarını belirtmiş olmalı (ve onsuz, hedef ortamları güncelleme girişimleri otomatik olarak başarısız olacaktır).

Bunlar, düşünebileceğim strateji / kalıplardır:

Görev Ayrımı

DevOps, en azından benim görüşüme göre, hem dev hem de op'ların tek bir kişide somutlaştırılması anlamına gelmiyor. Bu nedenle, görevi (dev) kodunu yazan kişi onu yürüten kişi olmayacak şekilde ayırmak hala mümkündür.

Örneğin, canlı ortamda bir SQL ifadesi çalıştırılacaksa, biri SQL'yi yazar, diğeri bunu çalıştırır. Bunun öngörüldüğü şey, yürütücünün SQL hakkında bir anlayışa sahip olması ve sadece yürütmek zorunda olmamasıdır.

Tetikleyiciyi dağıt

Sürekli dağıtım haklı olmasına rağmen. Daha düzenli bir sektördeki ekip, konuşlandırmayı otomatik olarak dağıtmak yerine tetiklemek üzere başka (ayrı) bir taraf atayabilir. Kontrol listesi, otomatik testler, sağlama toplamları dağıtımı tetiklemeden önce olası kontrollerdir.

Bir kez tetiklendiğinde, otomasyon konuşlandırmayı yürütmek için devam edebilir.

Çiftler programı

Şahsen ben bu tekniği kontrol ve denge prensibini yerine getirmek için denetçinin bir yöntemi olarak belirtmedim. Ancak potansiyel olarak bunun bir strateji olabileceğini düşünüyorum.

MFA

Bununla biraz uzuyor olabilirim, ancak bir nedenden dolayı bir sisteme tek taraflı giriş yapmak istemiyorsanız, birisi şifreyi, bir başkası belirteci veya cihazı bir defa kodunu tutabilir. Bu nedenle, sistemi değerlendirmek için 2 kişi hazır bulunmalıdır.