Bir mimari sayfasının amacı, bir hizmetin veya projenin mimari, amaç ve güvenlik kontrollerini belgelemektir. Bu proje için en iyi uygulama dağıtımını belgelemelidir.
Mimari sayfada bazı önemli bölümler bulunmaktadır. Bunlar aşağıda daha ayrıntılı olarak açıklanmıştır:
Başlık, sürüm bilgisi, iletişim detayları
Proje açıklaması ve amaç
Birincil kullanıcılar ve kullanım örnekleri
Harici bağımlılıklar ve ilişikili güvenlik varsayımları
Bileşenler
Mimari diyagram
Veri varlıkları
Veri varlık etkileri analizi
Arayüzler
Bu bölüm, mimari sayfanın başlığını taşıyor, incelemenin durumunu (taslak, incelenmeye hazır, incelenmiştir) verir ve projenin yayın ve sürümünü (ilgili olduğu yerde) yakalar. Ayrıca, projenin PTL’sini, mimari sayfayı üretmekten sorumlu olan projenin mimarını, diyagramları ve incelemenin (bu PTL olabilir veya olmayabilir) ve güvenlik incelemeci(ler)sinin çalışmasını da kaydeder.
Bu bölüm, projeye üçüncü kişileri tanıtmak için projenin kısa bir açıklamasını içerecektir. Bu bir veya iki paragraf olmalı ve wiki veya diğer dokümanlardan kes / yapıştır yapılabilir. İlgili sunulara ve varsa daha fazla belgeye bağlantıları ekleyin.
Örneğin:
“Çapa, kararların verilmesini otomatikleştirmek için otomatik sertifika isteği doğrulamasını kullanan bir ortak anahtar altyapısı (PKI) servisidir. Sertifikalar, CRL’ler ve OCSP ile ilgili hatalı iptal sorunlarını önlemek için kısa sürelerle (genellikle 12-48 saat) yayınlanmaktadır.”
Uygulanan mimarinin beklenen birincil kullanıcılarının ve kullanım durumlarının bir listesi. ‘Kullanıcılar’, aktörler veya OpenStack içindeki diğer servisler olabilir.
Örneğin:
Son kullanıcılar, sistemi parolalar şifreleme anahtarları vb. gibi hassas verileri depolamak için kullanır.
Bulut yöneticileri kaynak kotalarını yönetmek için yönetimsel API’leri kullanır.
Harici bağımlılıklar, servisin çalışması için gerekli olan denetim dışındaki öğelerdir ve serviste açık olduğunda veya kullanılamaz duruma gelindiğinde bu servisi etkileyebilir. Bu öğeler genellikle geliştiricinin kontrolü dışındadır ancak dağıtımcının denetimi altında veya üçüncü taraflar tarafından işletilebilirler. Aletler dış bağımlılıklar olarak değerlendirilmelidir.
Örneğin:
Nova hesaplama servisi, harici kimlik doğrulama ve yetkilendirme hizmetine bağlıdır. Tipik bir dağıtımda bu bağımlılık, keystone servisi ile yerine getirilecek.
Barbican, Donanım Güvenlik Modülü (HSM) kullanımına bağlı.
Dış öğeleri hariç tutarak dağıtılan projenin bileşenleri listesi. Her bileşen adlandırılmalı ve amacına ilişkin kısa bir açıklama yapmalı ve kullanılan birincil teknoloji ile etiketlenmelidir (ör. Python, MySQL, RabbitMQ).
Örneğin:
keystone dinleyici süreci (Python): Keystone servisi tarafından yayınlanan keystone olaylarını tüketen Python işlemi.
Veritabanı (MySQL): Yönetilen varlıklar ve metaverileri ile ilgili barbican durum verilerini saklamak için MySQL veritabanı.
Mimari diyagram, sistemin mantıksal düzenini gösterir, böylece güvenlik incelemecileri proje ekibi ile birlikte mimariye adım atabilir. Bileşenlerin nasıl etkileşim kurduğunu, dış varlıklarla nasıl bağlantı kurduklarını ve iletişimlerin güven sınırlarını aştıklarını gösteren mantıksal bir diyagramdır. Mimari diyagramında, sembollerin bir anahtarı da dahil olmak üzere daha fazla bilgi gelecek mimari şema rehberinde verilecektir. Diyagramlar tuştaki sembolleri kullanan bir diyagram oluşturabilen herhangi bir araçta çizilebilir, ancak draw.io şiddetle önerilir.
Bu örnek, barbican mimari diyagramı gösterir:
Veri varlıkları, bir saldırganın hedefleyebileceği kullanıcı verileri, yüksek değerli veriler, yapılandırma öğeleri, yetkilendirme belirteçleri veya diğer öğelerdir. Veri kalemleri projelere göre değişir, ancak genel olarak projenin amaçlanan çalışması için hayati önem taşıyan veri sınıfları olarak düşünülmelidir. Gerekli detay seviyesi biraz bağlama bağlıdır. Veriler genellikle ‘kullanıcı verileri’, ‘gizli veriler’ veya ‘yapılandırma dosyaları’ gibi gruplanabilir, ancak ‘yönetici kimliği belirteci’ veya ‘kullanıcı kimliği belirteci’ veya ‘veritabanı yapılandırma dosyası’ gibi tekil olabilir.
Veri varlıkları, varlığın nerede kalacağına dair bir bildirim içermelidir.
Örneğin:
Gizli veriler - Parola deyimleri, Şifreleme Anahtarları, RSA Anahtarları - Veritabanı [PKCS#11] veya HSM [KMIP] veya [KMIP, Dogtag]
RBAC kural kümeleri - policy.json dosyasında saklanır
RabbitMQ Kimlik Bilgileri - barbican.conf dosyasında saklanır
keystone Olay Kuyruk Kimlik Bilgileri - barbican.conf dosyasında saklanır
Ara katman yapılandırması - paste.ini dosyasında saklanır
Veri varlığı etki analizi, her bir veri öğesi için gizlilik, bütünlük veya kullanılabilirlik kaybının etkisini ortadan kaldırır. Proje mimarları, projelerini en ayrıntılı şekilde anladıkları için bunu tamamlamaya çalışmalıdırlar ancak OpenStack Güvenlik Projesi (OSSP) güvenlik incelemesi sırasında projeyle birlikte çalışacak ve etki ayrıntılarını ekleme veya güncelleme olasılığı yüksektir.
Örneğin:
RabbitMQ kimlik bilgileri:
Bütünlük Başarısızlığı Etkisi: barbican ve Worker’lar kuyruğa artık erişemezler. Hizmet reddi.
Gizlilik Başarısızlığı Etkisi: Bir saldırgan, sıraya worker’lar tarafından uygulanacak yeni görevler ekleyebilir. Kullanıcı kotaları bir saldırgan tarafından tüketilebilir. DoS. Kullanıcı gerçek sırları oluşturamaz.
Kullanılabilirlik Başarısızlığı Etkisi: barbican sıraya erişmeksizin artık yeni gizli bilgi oluşturamaz.
keystone kimlik bilgileri:
Bütünlük Başarısızlığı Etkisi: barbican, kullanıcı kimlik bilgilerini doğrulayamaz ve başarısız olur. DoS.
Gizlilik Başarısızlığı Etkisi: Kötü niyetli bir kullanıcı diğer OpenStack servislerini kötüye kullanabilir (keystone rolü yapılandırmalarına bağlı olarak) ancak barbican etkilenmez. Belirteç onaylaması için servis hesabı aynı zamanda barbican yönetici ayrıcalıklarına sahipse, kötü niyetli bir kullanıcı barbican yönetim işlevlerini değiştirebilir.
Kullanılabilirlik Başarısızlığı Etkisi: barbican, kullanıcı kimlik bilgilerini doğrulayamaz ve başarısız olur. DoS.
Arabirimler listesi, inceleme alanı içindeki arayüzleri yakalar. Bu, bir güven sınırını aşan veya TLS veya SSH gibi endüstri standardı şifreleme protokolünü kullanmayan mimari şemasındaki bloklar arasındaki bağlantıları içerir. Her arabirim için aşağıdaki bilgiler toplanır:
Kullanılan protokol
Bu arabirimde geçiş yapan herhangi bir veri varlığı
Bu arabirime bağlanmak için kullanılan kimlik doğrulama hakkında bilgi
Arayüzün amacını anlatan bir özet açıklama.
Bu, aşağıdaki biçimde kaydedilmiştir:
Kimden->Kime [Transport]:
Hareket halindeki varlıklar
Kimlik Doğrulama?
Açıklama
Örneğin:
İstemci->API Süreci [TLS]:
Uçuştaki varlıklar: Kullanıcı keystone kimlik bilgileri, düz metin gizli bilgiler, HTTP fiilleri, gizli kimlik, yol
Keystone kimlik belgelerine veya düz metin gizli bilgilere erişim, sistemin toplam güvenlik başarısızlığı olarak düşünülür - bu arayüz sağlam gizlilik ve bütünlük kontrollerine sahip olmalıdır.
Projeye ilişkin, kaynak ve kullanımını açıklayan wiki sayfaları, kod depolarına bağlantılar ve ilgili sunumlar gibi kaynakları listeleyin.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.