Sertifikalandırma ve uyum ifadeleri¶
Uyum ve güvenlik birbirinden ayrı değildir ve birlikte ele alınmalıdır. OpenStack dağıtımları güvenlik zorlaması olmadan uyumluluk gereksinimlerini karşılamak pek olası değildir. Aşağıdaki listede, ticari ve devlet sertifikalarına ve standartlarına uyumu sağlamak için bir OpenStack mimarı için temel bilgi ve rehberlik bulunmaktadır.
Kurumsal standartlar¶
OpenStack’in ticari dağıtımları için, OpenStack sertifikasyon faaliyetleri için bir başlangıç noktası olarak düşünülmesi için SOC 1/2 ürününün ISO 2700 1/2 ile birleşimini öneriyoruz. Bu sertifikalardan zorunlu olarak istenen güvenlik faaliyetleri, devlet envanteri ve sertifikaları da dahil olmak üzere daha sıkı uyum faaliyetlerine ulaşılmasına yardımcı olabilecek en iyi güvenlik uygulamaları ve ortak kontrol kriterlerinin temelini kolaylaştırır.
Bu ilk sertifikaları tamamladıktan sonra kalan sertifikalar dağıtıma özgüdür. Örneğin, kredi kartı işlemlerini işleme koyan bulutların PCI-DSS’ye, bulutların sağlık bilgileri depolamak için HIPAA’ya ve federal hükümet içindeki bulutların FedRAMP / FISMA ve ITAR sertifikalarına ihtiyaç duyması gerekir.
SOC 1 (SSAE 16) / ISAE 3402¶
Servis Organizasyonu Kontrolleri (SOC) kriterleri, American Institute of Certified Public Accountants (AICPA) tarafından tanımlanmaktadır. SOC kontrolleri, Sarbanes-Oxley Yasası’na uygunluk gibi bir :term: hizmet sağlayıcısı’nın ilgili mali tablolarını ve iddialarını değerlendirir. SOC 1, Denetim Standartları No.70 (SAS 70) Tip II raporu Beyannamesinin yerine geçer. Bu kontroller genelde fiziksel veri merkezlerini kapsar.
2 tür SOC 1 raporu vardır:
Tür 1 - servis organizasyonunun sistemi ile ilgili yönetim açıklamalarının sunumunun ve bu denetimin tasarımın belirli bir tarihte tanımlamaya dahil edilen ilgili kontrol hedeflerini gerçekleştirmeye uygunluğunu rapor eder.
Tür 2 - servis organizasyonunun sistemi ile ilgili yönetimin açıklamasının sunumunun adilliği ve açıklamalara dahil edilen ilgili kontrol hedeflerini belirli bir süre boyunca gerçekleştirmek için kontrollerin tasarımının ve işletme etkililiğinin uygunluğunu rapor eder
Daha fazla bilgi için, Mali Raporlama İç Kontrolü ‘ndeki ‘Kullanıcı Varlıklarıyla İlgili Bir Hizmet Organizasyonundaki Kontroller Üzerindeki AICPA Raporuna’ bakınız.
SOC 2¶
Servis Kuruluşu Denetimleri (SOC) 2, bir hizmet organizasyonunun kullanıcı verilerini işlemek için kullandığı sistemlerin güvenlik, kullanılabilirlik ve işleme bütünlüğünü etkileyen denetimlerin ve bu sistem tarafından işlenen bilgilerin gizliliğinin ve mahremiyetinin kendine özgü bir ispatıdır. Kullanıcı örnekleri, hizmet organizasyonunun yönetimi, hizmet organizasyonunun müşterileri, düzenleyiciler, iş ortakları, tedarikçiler ve hizmet organizasyonu ve kontrollerini anlayan diğer kişilerdir.
İki tür SOC 2 raporu vardır:
Tür 1 - servis organizasyonunun sistemi ile ilgili yönetim açıklamalarının sunumunun ve bu denetimin tasarımın belirli bir tarihte tanımlamaya dahil edilen ilgili kontrol hedeflerini gerçekleştirmeye uygunluğunu rapor eder.
Tür 2 - servis organizasyonunun sistemi ile ilgili yönetim açıklamalarının sunumunun adilliği ve açıklamalara dahil edilen ilgili kontrol hedeflerini belirli bir süre boyunca yerine getirmek için kontrollerin tasarım ve işletme verimliliğinin uygunluğunu rapor eder.
Daha fazla ayrıntı için bkz. Güvenlik, Kullanılabilirlik, İşleme Dürüstlüğü, Gizlilik veya Gizlilikle İlgili Bir Servis Organizasyonundaki Kontroller Üzerine AICPA Raporu <http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx> _.
SOC 3¶
Servis Organizasyonu Denetimleri (SOC) 3, servis organizasyonları için bir güvenlilik hizmetleri raporudur. Bu raporlar, bir servis organizasyonundaki güvenlik, kullanılabilirlik, işleme bütünlüğü, gizlilik veya gizlilik ile ilgili kontroller konusunda güvence isteyen kullanıcıların ihtiyaçlarını karşılamak üzere tasarlanmıştır; ancak, bu hizmetlerin etkinliğini sağlamak için gerekli bilgiye veya bilgiye ihtiyaç duymazlar. SOC 2 Raporu. Bu raporlar, AICPA / Kanadalı Yeminli Mali Müşavirler Enstitüsü (CICA) Güven Hizmetleri İlkeleri, Kriterleri ve Güvenlik, Kullanılabilirlik, İşleme Dürüstlük, Gizlilik ve Gizlilik İçin İllüstrasyonlar kullanılarak hazırlanmıştır. Genel kullanım raporları oldukları için, SOC 3 Raporları bir web sitesinde mühür olarak serbestçe dağıtılabilir veya yayınlanabilir.
Daha fazla ayrıntı için bkz. AICPA Hizmet Kuruluşları İçin Güven Hizmetleri Raporu.
ISO 27001/2¶
ISO/IEC 27001/2 standartları BS7799-2’nin yerini almış ve bir Bilgi Güvenliği Yönetim Sistemi (ISMS) için şartnamelerdir. Bir ISMS, bir kuruluşun bilgi varlıkları için riski yönetmek için oluşturduğu ve koruduğu kapsamlı bir politika ve süreçler dizisidir. Bu riskler, kullanıcı bilgilerinin gizliliği, bütünlüğü ve kullanılabilirliği (CIA) temel alır. CIA güvenlik üçlüsü bu kitabın pek çok bölümünün temeli olarak kullanılmıştır.
Daha fazla bilgi için bkz. ISO 27001.
HIPAA / HITECH¶
Sağlık Sigortası Taşınabilirliği ve Hesap Verebilirlik Yasası (HIPAA), hasta sağlık kayıtlarının toplanmasını, depolanmasını, kullanılmasını ve tahrip edilmesini yöneten Birleşik Devletler Kongresi yasasıdır. Yasaya göre Korunan Sağlık Bilgisi (PHI), yetkisiz kişilere “kullanılamaz, okunamıyor veya okunaksız hale getirilmelidir” ve verilerin “dinlenme” ve “uçuş için” şifrelenmesi için ele alınmalıdır.
HIPAA bir belgelendirme değil, sağlık verilerinin korunması için bir rehberdir. PCI-DSS’ye benzer şekilde hem PCI hem de HIPPA ile ilgili en önemli hususlar, kredi kartı bilgilerinin ve sağlık verilerinin ihlal edilmemesidir. Bir ihlal durumunda, bulut sağlayıcı PCI ve HIPPA kontrollerine uyum için incelenecek. Uyumlu olduğu ispatlanırsa, sağlayıcının düzeltici kontrolleri derhal uygulamasını, bildirim sorumluluklarını ihlal etmesini ve ek uygunluk faaliyetlerinde önemli miktarda harcamayı beklemesi beklenebilir. Uyumlu değilse, bulut sağlayıcısı, yerinde denetim ekipleri, cezalar, olası ticari kimliğini kaybetme (PCI) ve büyük itibar etkisi içerebilir.
PHI’ya sahip kullanıcılar veya kuruluşlar, HIPAA gereksinimlerini desteklemeli ve HIPAA kapsamında olan varlıklardır. Bir işletme bir hizmeti veya bu durumda bu PHI’yi kullanabilen, depolayan veya erişebilen bir OpenStack bulutu kullanmayı planlıyorsa, bir İş Ortağı Sözleşmesi (BAA) imzalanmalıdır. BAA, HIPAA kapsamındaki varlık ile OpenStack servis sağlayıcı arasında, tedarikçinin söz konusu PHI’yi HIPAA gereklerine uygun şekilde kullanmasını gerektiren bir sözleşmedir. Servis sağlayıcı, PHI’yı güvenlik kontrolleri ve sertleştirme gibi işleyemezse, HIPAA cezalarına ve cezalarına tabidir.
OpenStack mimarları, HIPAA ifadelerini yorumluyor ve yanıtlıyorlar; veri şifrelemesi çekirdek bir uygulama olmaya devam ediyor. Halen bu, bir OpenStack dağıtımında bulunan korunan sağlık bilgisinin endüstri standardı şifreleme algoritmaları ile şifrelenmesini gerektirir. Nesne şifrelemesi gibi potansiyel gelecekteki OpenStack projeleri, HIPAA kurallarını hareketle uyumu kolaylaştıracaktır.
Daha fazla bilgi için bkz. Sağlık Sigortası Taşınabilirliği ve Hesap Verebilirlik Yasası.
PCI-DSS¶
Ödeme Kartı Endüstrisi Veri Güvenliği Standardı (PCI DSS), Ödeme Kartı Endüstrisi Standartları Konseyi tarafından tanımlanır ve kredi kartı dolandırıcılığını azaltmak için kart sahibi verileri etrafındaki denetimleri artırmak için oluşturulmuştur. Yıllık uyum geçerliliği, bir Uygunluk Raporu (ROC) oluşturan harici bir Nitelikli Güvenlik Testi Uzmanı (QSA) veya kart sahibinin işlem hacmine bağlı olarak bir Özdeğerlendirme Anketi (SAQ) tarafından değerlendirilir.
Ödeme kartı ayrıntılarını saklayan, işleyen veya ileten OpenStack dağıtımları PCI-DSS kapsamındadır. Ödeme verilerini işleyen sistemlerden veya ağlardan düzgün şekilde bölünmemiş olan tüm OpenStack bileşenleri PCI-DSS’nin kurallarına girmektedir. PCI-DSS bağlamında segmentasyon, çoklu kiracılığı değil, fiziksel ayrımı (ana / ağ) desteklemez.
Daha fazla bilgi için bkz. PCI güvenlik standartları.
Hükümet standartları¶
FedRAMP¶
“Federal Risk ve Yetkilendirme Yönetim Programı (http://www.fedramp.gov) _ (FedRAMP), bulut ürünleri ve hizmetleri için güvenlik değerlendirmesi, yetkilendirme ve sürekli izleme için standart bir yaklaşım sağlayan hükümet çapında bir programdır “. NIST 800-53, bulut ortamlarında koruma sağlamak için özel olarak seçilmiş güvenlik kontrollerini zorlayan FISMA ve FedRAMP için temel oluşturmaktadır. FedRAMP, güvenlik kontrolleri etrafındaki özgüllükten ve hükümet standartlarını karşılamak için gereken belgelerin hacminden son derece yoğun olabilir.
Daha fazla bilgi için bkz. FedRAMP.
ITAR¶
Silah Düzenlemelerinde Uluslararası Trafik (ITAR), Birleşik Devletler Silahlı Kuvvetleri Listesinde (USML) ve ilgili teknik verilere ilişkin savunma ile ilgili makalelerin ve hizmetlerin ihracatını ve ithalini denetleyen bir dizi Birleşik Devletler hükümet düzenlemesidir. ITAR genellikle bulut sağlayıcıları tarafından resmi bir sertifika yerine “operasyonel uyum” olarak ele alınmaktadır. Bu, tipik olarak, yalnızca “ABD’li Kişiler” e erişimi kısıtlayan ilave kontrollerle ve arka plan taramayla tamamlanan, FISMA gerekliliklerine göre NIST 800-53 çerçevesine dayanan uygulamaları takiben ayrı bir bulut ortamının uygulanmasını içerir.
Daha fazla bilgi için bkz. Silaha Düzenlemelerinde Uluslararası Trafik (ITAR).
FISMA¶
Federal Bilgi Güvenliği Yönetim Yasası, devlet kurumlarının çok sayıda hükümet güvenlik standartlarını uygulamak için kapsamlı bir plan hazırlamasını ve 2002 yılının E-Devlet Yasasında çıkartılmasını gerektirir. FISMA, çok sayıda NIST yayını kullanan bir saklama prosedürü hazırlar ve hükümet verilerini işler.
Bu süreç üç ayrı ana kategoriye ayrılır:
- Sistem kategorilendirmesi:
Bilgi sistemi Federal Bilgi İşleme Standartları Yayın 199 (FIPS 199) ‘da tanımlanan bir güvenlik kategorisi alacaktır. Bu kategoriler, sistemin tehlikelerinin potansiyel etkisini yansıtmaktadır.
- Kontrol seçimi:
FIPS 199’da tanımlanan sistem güvenlik kategorisine dayanarak, bir organizasyon bilgi sistemi için belirli güvenlik kontrol gereksinimlerini tanımlamak için FIPS 200’ü kullanmaktadır. Örneğin, bir sistem “orta” olarak kategorize edilirse, “güvenli parolalar” ı zorunlu kılmak için bir gereklilik getirilebilir.
- Kontrol hazırlığı:
Sistem güvenlik kontrolleri tanımlandıktan sonra, bir OpenStack mimarı, özel kontrol seçimi için NIST 800-53’ü kullanacaktır. Örneğin, “güvenli parola”yı neyin oluşturduğunun belirtimi.
