監査プロセスを理解する

情報システムのセキュリティコンプライアンスは、二つの基本的なプロセスの完了を前提としています。

セキュリティーコントロールの導入および運用

Aligning the information system with in-scope standards and regulations involves internal tasks which must be conducted before a formal assessment. Auditors may be involved at this state to conduct gap analysis, provide guidance, and increase the likelihood of successful certification.

独立した検査と検証

システムのセキュリティコントロールが標準と規制の範囲に従って実装され、効率的に運用されているか。これを中立的な第三者へ、認証を得る以前に証明しなければなりません。多くの認証は、その継続を保証するため、包括的な継続監視の一部として、定期的な監査を必要とします。

監査の範囲を決定する

何をコントロールするのか、OpenStack環境をいかにデザイン、変更していくかを明確にするため、監査範囲は初期の計画段階で決定すべきです。

OpenStack環境の範囲をコンプライアンス目的で明確化する際は、制御機能や仮想化技術など、慎重に扱うべきサービスの周辺を優先度付けしてください。それらを妥協することは、OpenStack環境全体に影響を与えかねません。

範囲を限定することで、限定された環境に対し、OpenStackの設計者は高いセキュリティ品質を確立しやすくなります。しかしその取り組みの中で、セキュリティ強化の範囲や機能を不当に省かないことが重要です。典型的な例はPCI-DSSガイドラインです。決済に関わるインフラはセキュリティを精査されるでしょう。が、その影でその周辺サービスが放置されれば、そこが攻撃に対し無防備となります。

コンプライアンスに取り組む際、複数の認証で共通の領域と基準を明確にできれば、効率的に手間を減らすことができます。この本で取り上げている監査原則とガイドラインの多くは、それらを特定するのに役立ちます。加えて、総合的なリストを提供するガイドラインが多くあります。以下に例を挙げます。

The Cloud Security Alliance Cloud Controls Matrix (CCM) assists both cloud providers and consumers in assessing the overall security of a cloud provider. The CSA CMM provides a controls framework that map to many industry-accepted standards and regulations including the ISO 27001/2, ISACA, COBIT, PCI, NIST, Jericho Forum and NERC CIP.

The SCAP Security Guide is another useful reference. This is still an emerging source, but we anticipate that this will grow into a tool with controls mappings that are more focused on the US federal government certifications and recommendations. For example, the SCAP Security Guide currently has some mappings for security technical implementation guides (STIGs) and NIST-800-53.

これらのコントロールマッピングは、認証間で共通の統制基準を特定します。また、監査人と被監査者両方にとって問題となる、特定のコンプライアンス認証、認定に必要なコントロールセットを可視化するのに役立ちます。

監査フェーズ

An audit has four distinct phases, though most stakeholders and control owners will only participate in one or two. The four phases are Planning, Fieldwork, Reporting and Wrap-up. Each of these phases is discussed below.

The Planning phase is typically performed two weeks to six months before Fieldwork begins. In this phase audit items such as the timeframe, timeline, controls to be evaluated, and control owners are discussed and finalized. Concerns about resource availability, impartiality, and costs are also resolved.

The Fieldwork phase is the most visible portion of the audit. This is where the auditors are onsite, interviewing the control owners, documenting the controls that are in place, and identifying any issues. It is important to note that the auditors will use a two part process for evaluating the controls in place. The first part is evaluating the design effectiveness of the control. This is where the auditor will evaluate whether the control is capable of effectively preventing or detecting and correcting weaknesses and deficiencies. A control must pass this test to be evaluated in the second phase. This is because with a control that is designed ineffectually, there is no point considering whether it is operating effectively. The second part is operational effectiveness. Operational effectiveness testing will determine how the control was applied, the consistency with which the control was applied and by whom or by what means the control was applied. A control may depend upon other controls (indirect controls) and, if they do, additional evidence that demonstrates the operating effectiveness of those indirect controls may be required for the auditor to determine the overall operating effectiveness of the control.

The Reporting phase is where any issues that were identified during the Fieldwork phase will be validated by management. For logistics purposes, some activities such as issue validation may be performed during the Fieldwork phase. Management will also need to provide remediation plans to address the issues and ensure that they do not reoccur. A draft of the overall report will be circulated for review to the stakeholders and management. Agreed upon changes are incorporated and the updated draft is sent to senior management for review and approval. Once senior management approves the report, it is finalized and distributed to executive management. Any issues are entered into the issue tracking or risk tracking mechanism the organization uses.

The Wrap-up phase is where the audit is officially spun down. Management will begin remediation activities at this point. Processes and notifications are used to ensure that any audit related information is moved to a secure repository.

内部監査

クラウドが導入されたのであれば、内部監査が必要です。あなたが採用を決めた統制基準と、あなたのクラウドの設計、機能、配備戦略を比較する時です。目的はそれぞれの統制がどのように扱われているか、ギャップがどこに存在するか、理解することです。そして、その全てを将来のために文書化します。

OpenStackクラウドを監査するとき、OpenStackアーキテクチャ固有のマルチテナント環境を理解することが重要です。データの廃棄、ハイパーバイザーのセキュリティ、ノードの強化、および認証メカニズムなど、いくつか重要な部分があります。

外部監査に備える

内部監査の結果が良好であれば、いよいよ外部監査の準備です。この段階では、いくつかの鍵となる活動があります。概要は以下です。

• 内部監査での良好な状態を維持してください。それらは外部監査の実施期間に証明として役立ちます。またそれは、コンプライアンス統制に関する詳細な質疑応答の備えとなります。

• クラウドがコンプライアンスを維持し続けるために、自動テストツールを導入してください。

• 監査人を選ぶ

監査人の選定は困難を伴うことがあります。クラウドのコンプライアンス監査経験がある人を見つけてくるのが理想です。OpenStackの経験があれば、なお良しです。このプロセスを経験している人に相談するのがベストでしょう。なお、費用は契約の範囲と監査法人に大きく依存します。

外部監査

これが正式な監査プロセスです。監査人は、特定の認定向けのセキュリティ統制を確認し、これらの統制が監査期間において整っているか証明する根拠を要求します (たとえば、SOC 2監査は一般的に6-12ヶ月のセキュリティ統制を評価します)。どのような統制上の不具合も記録され、外部監査の最終報告書で文書化されます。OpenStack環境の種別に依存しますが、これらの報告書は顧客に公開されるでしょう。それゆえ統制上の不具合を避けることは重要です。これが監査への準備が重要であることの理由です。

コンプライアンスの維持

The process does not end with a single external audit. Most certifications require continual compliance activities which means repeating the audit process periodically. We recommend integrating automated compliance verification tools into a cloud to ensure that it is compliant at all times. This should be in done in addition to other security monitoring tools. Remember that the goal is both security and compliance. Failing on either of these fronts will significantly complicate future audits.