認証とコンプライアンスの報告書¶
コンプライアンスとセキュリティは排他的でなく、あわせて取り組むべきものです。OpenStack環境は、セキュリティの強化なしに、コンプライアンス要件を充足することができないでしょう。以下のリストは、OpenStackアーキテクト向けの、商業規格および政府機関の認証を得るための基本的な知識とガイダンスです。
商業規格¶
For commercial deployments of OpenStack, we recommend SOC 1/2 is combined with ISO 2700 1/2 to be considered as a starting point for OpenStack certification activities. The required security activities mandated by these certifications facilitate a foundation of security best practices and common control criteria that can assist in achieving more stringent compliance activities, including government attestations and certifications.
これらの基本的認証を取得したのち、より環境特有の認証を検討します。たとえば、クラウドがクレジットカードのトランザクションを扱うのであればPCI-DSSが必要ですし、ヘルスケア情報を保持するならHIPPAが、連邦政府向けにはFedRAMP/FISMA、ITAR認証が必要となるでしょう。
SOC 1 (SSAE 16) / ISAE 3402¶
Service Organization Controls (SOC) criteria are defined by the American Institute of Certified Public Accountants (AICPA). SOC controls assess relevant financial statements and assertions of a service provider, such as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing Standards No. 70 (SAS 70) Type II report. These controls commonly include physical data centers in scope.
SOC 1報告書には二つの種類があります。
Type 1 - サービス提供組織がその管理について説明し、その公正さをレポートします。特定時点で関連する管理対象を統制できているか、その設計の持続可能性も報告します。
Type 2 - サービス組織が統制対象を統制するために使用するシステム、設計の持続性、および運用効率性に関する管理者の説明内容が公正かをレポートします。特定期間を通しての説明も必要です。
For more details see the AICPA Report on Controls at a Service Organization Relevant to User Entities' Internal Control over Financial Reporting.
SOC 2¶
Service Organization Controls (SOC) 2 is a self attestation of controls that affect the security, availability, and processing integrity of the systems a service organization uses to process users' data and the confidentiality and privacy of information processed by these system. Examples of users are those responsible for governance of the service organization, customers of the service organization, regulators, business partners, suppliers, and others who have an understanding of the service organization and its controls.
SOC 2報告書には二つの種類があります。
Type 1 - サービス提供組織がその管理について説明し、その公正さをレポートします。特定時点で関連する管理対象を統制できているか、その設計の持続可能性も報告します。
Type 2 - サービス組織が統制対象を統制するために使用するシステム、設計の持続性、および運用効率性に関する管理者の説明内容が公正かをレポートします。特定期間を通しての説明も必要です。
For more details see the AICPA Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy.
SOC 3¶
Service Organization Controls (SOC) 3はサービス提供組織のための公的なサービス報告書です。これらのレポートはサービス組織のセキュリティ、可用性、処理の完全性、機密性、またはプライバシーに関する統制の保証を求めるユーザーニーズを満たすためのレポートです。ただし、SOC 2報告書ほどの情報は必要ありません。SOC 3報告書はAICPA/Canadian Institute of Chartered Accountants (CICA)のTrust Services Principles, Criteria, and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacyをもって作成されています。SOC 3は一般的に使われる報告書であり、Webサイト上で証明書として自由に配布できます。
For more details see the AICPA Trust Services Report for Service Organizations.
ISO 27001/2¶
ISO/IEC 27001/2はBS7799-2の後継標準で、Information Security Management System (ISMS)の要件です。ISMSは組織が情報資産のリスクを管理するために作成、維持する、ポリシーとプロセスの包括的なセットです。それらのリスクはユーザー情報のConfidentiality - 機密性、Integrity - 完全性、および Availability - 可用性 (CIA)に深く関係しています。CIAセキュリティの三要素は、このガイドの多くの章で基本となっています。
For more details see ISO 27001.
HIPAA / HITECH¶
Health Insurance Portability and Accountability Act (HIPAA)は米国の健康保険における可搬性と責任に関する法律で、カルテ情報の収集、保存、および廃棄に関するルールを定めています。この法律は、保護医療情報 (Protected Health Information, PHI)は、権限のない人が"利用できない、読めない、複合できない"ように変換されなければいけないこと、また、データが保存中でも、処理中でも、暗号化するべきであることに言及しています。
HIPAA is not a certification, rather a guide for protecting healthcare data. Similar to the PCI-DSS, the most important issues with both PCI and HIPPA is that a breach of credit card information, and health data, does not occur. In the instance of a breach, the cloud provider will be scrutinized for compliance with PCI and HIPPA controls. If proven compliant, the provider can be expected to immediately implement remedial controls, breach notification responsibilities, and significant expenditure on additional compliance activities. If not compliant, the cloud provider can expect on-site audit teams, fines, potential loss of merchant ID (PCI), and massive reputation impact.
Users or organizations that possess PHI must support HIPAA requirements and are HIPAA covered entities. If an entity intends to use a service, or in this case, an OpenStack cloud that might use, store or have access to that PHI, then a Business Associate Agreement (BAA) must be signed. The BAA is a contract between the HIPAA covered entity and the OpenStack service provider that requires the provider to handle that PHI in accordance with HIPAA requirements. If the service provider does not handle the PHI, such as with security controls and hardening, then they are subject to HIPAA fines and penalties.
OpenStack architects interpret and respond to HIPAA statements, with data encryption remaining a core practice. Currently, this would require any protected health information contained within an OpenStack deployment to be encrypted with industry standard encryption algorithms. Potential future OpenStack projects such as object encryption will facilitate HIPAA guidelines for compliance with the act.
For more details see the Health Insurance Portability And Accountability Act.
PCI-DSS¶
Payment Card Industry Data Security Standard (PCI DSS)はPayment Card Industry Standards Councilで定義されました。目的は、クレジットカード不正の防止のため、カード所有者情報に関する統制度を向上することです。コンプライアンス検査は年次で、外部のコンプライアンス評価報告書(Report on Compliance, ROC)を作成する認定評価機関 (Qualified Security Assessor, QSA)、もしくは、自己評価問診票(Self-Assessment Questionnaire, SAQ)によって実施されます。これはカード所有者のトランザクション量に依存します。
OpenStack deployments that store, process, or transmit payment card details are in scope for the PCI-DSS. All OpenStack components that are not properly segmented from systems or networks that handle payment data fall under the guidelines of the PCI-DSS. Segmentation in the context of PCI-DSS does not support multi-tenancy, but rather physical separation (host/network).
For more details see PCI security standards.
政府標準¶
FedRAMP¶
"The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services". NIST 800-53 is the basis for both FISMA and FedRAMP which mandates security controls specifically selected to provide protection in cloud environments. FedRAMP can be extremely intensive from specificity around security controls, and the volume of documentation required to meet government standards.
For more details see FedRAMP.
ITAR¶
International Traffic in Arms Regulations (ITAR)は米国政府規制の集合であり、米国軍需品リスト(United States Munitions List, USML)と関連技術情報に関係する防衛物品・サービスの輸出入を統制します。ITARは正式な認証というより、"軍事活動支援"の位置づけでクラウドプロバイダーから提示されます。この統制は一般的に、NIST 800-53フレームワークにもとづき、分離されたクラウド環境の実装を意味します。FISMA要件により、米国民かつ身元審査された人のみがアクセスできるよう、追加の統制で補完します。
For more details see The International Traffic in Arms Regulations (ITAR).
FISMA¶
米国連邦情報セキュリティマネジメント法 - Federal Information Security Management Act requires、FISMAは、政府機関は多数の政府セキュリティ標準を実装するために、包括的な計画を作成する必要があるとして、2002年 電子政府法 - E-Government Act of 2002 内で制定されました。FISMAは多数のNIST公表文献を活用し、政府のデータを保存、処理する情報システムを作成するためのプロセスを説明しています。
このプロセスは三つの主要カテゴリに分割されています。
- システムのカテゴリー分類:
情報システムは連邦情報処理規格( Federal Information Processing Standards Publication 199, FIPS 199)で定められたセキュリティカテゴリに分類されます。これらのカテゴリはシステムの情報漏洩の潜在的な影響を反映しています。
- コントロールの選択:
FIPS 199で定められたシステムセキュリティのカテゴリにもとづき、組織は情報システムのための特定のセキュリティ統制要求を特定すべく、FIPS 200を活用します 。たとえば、もしシステムが「中程度」と分類されているのであれば、「安全なパスワード」の強制が求められるでしょう。
- コントロールのカスタマイズ:
システムセキュリティーコントロールが識別されると、OpenStack アーキテクトは、NIST 800-53 を利用して、カスタマイズしたコントロールを抽出します。例えば、「セキュアなパスワード」を構成するものの仕様。
