継続的なシステム管理¶
クラウドには必ずバグがあります。その中にはセキュリティの問題も含まれています。このような理由から、セキュリティ更新や一般的なソフトウェア更新の適用準備を行うことが極めて重要です。例えば、構成管理ツールを賢く利用していくことになります。これについては以下で説明しています。また、アップグレードが必要な時期を把握することも重要です。
脆弱性管理¶
For announcements regarding security relevant changes, subscribe to the OpenStack Announce mailing list. The security notifications are also posted through the downstream packages, for example, through Linux distributions that you may be subscribed to as part of the package updates.
OpenStack のコンポーネントは、クラウドにあるソフトウェアのごく一部です。これらだけではなく他のコンポーネントすべてを最新の状態に保つことが重要です。データソースはそれぞれデプロイメント固有となりますが、クラウド管理者は必要なメーリングリストを購読して、組織の環境に適用できるセキュリティ更新の通知を受信できるようにすることが重要です。通常、Linux のアップストリームディストリビューションをチェックするのと同じくらいシンプルです。
注釈
OpenStack は 2 つのチャネルからセキュリティ情報を発信しています。
OpenStack Security Advisories (OSSA) are created by the OpenStack Vulnerability Management Team (VMT). They pertain to security holes in core OpenStack services. More information on the VMT can be found in Vulnerability Management Process.
OpenStack Security Notes (OSSN) are created by the OpenStack Security Group (OSSG) to support the work of the VMT. OSSN address issues in supporting software and common deployment configurations. They are referenced throughout this guide. Security Notes are archived at OSSN.
トリアージ¶
After you are notified of a security update, the next step is to determine how critical this update is to a given cloud deployment. In this case, it is useful to have a pre-defined policy. Existing vulnerability rating systems such as the common vulnerability scoring system (CVSS) do not properly account for cloud deployments.
以下の例では、権限昇格、DoS (サービス妨害)、情報開示の 3 つのカテゴリーに脆弱性を分類した評価一覧表を紹介しています。脆弱性の種類やインフラストラクチャー内での発生箇所を理解することで、裏付けに基いた対応意思決定を下すことができます。
Privilege Escalation describes the ability of a user to act with the privileges of some other user in a system, bypassing appropriate authorization checks. A guest user performing an operation that allows them to conduct unauthorized operations with the privileges of an administrator is an example of this type of vulnerability.
サービス妨害 (DoS) とは、サービスやシステムの中断を引き起こす脆弱性を悪用することを指します。これには、ネットワークリソースを大量に使用する分散型攻撃や、リソース割り当てのバグや誘導型でのシステム障害の問題などで一般的に引き起こされるシングルユーザー攻撃の両方が含まれます。
情報開示の脆弱性は、システムや操作の情報を公開します。これらの脆弱性は、情報開示のデバッグから認証情報やパスワードなどの重要なセキュリティデータの公開などが当てはまります。
攻撃者の位置付け/権限レベル |
||||
|---|---|---|---|---|
外部 |
クラウドユーザー |
クラウドの管理者 |
制御プレーン |
|
権限昇格 (3 つのレベル) |
重要 |
なし |
なし |
なし |
権限昇格 (2 つのレベル) |
重要 |
重要 |
なし |
なし |
権限昇格 (1つのレベル) |
重要 |
重要 |
重要 |
なし |
サービス妨害 (DoS) |
高 |
中 |
低 |
低 |
情報開示 |
重要/高 |
重要/高 |
中/低 |
低 |
この表は、デプロイメントの発生箇所や影響をもとに脆弱性から受ける影響レベルを測定するための一般的な手法を示しています。例えば、Compute API ノードで権限レベルを 1 つ昇格すると、API の標準ユーザーはこのノード上の root ユーザーと同等の権限にまで昇格することが可能です。
クラウド管理者が、さまざまなセキュリティレベルに合わせて実行するアクションを定義する役に立てるために、この表をモデルとして使用することを推奨します。例えば、レベルが「重要」であるセキュリティ更新では、迅速にクラウドのアップグレードが必要となる可能性がありますが、レベルが「低」の更新では完了までもう少し時間をとれるでしょう。
更新のテスト¶
何らかの更新を本番環境にデプロイする前に、それらをテストするようにしてください。一般的に、更新を最初に受信するテスト用のクラウド設定が別途必要になります。このクラウドのソフトウェアやハードウェアはできるだけ実稼働クラウドと同じ環境にする必要があります。パフォーマンスの影響、安定性、アプリケーションへの影響など、更新全体をテストする必要があります。特に重要なのは、更新で理論上対応されている問題 (例: 特定の脆弱性) が実際に修正されているかどうかを確認することです。
更新のデプロイ¶
更新の完全なテストが終了すると、実稼働環境にデプロイすることができます。このデプロイメントは、以下に記載の構成管理ツールで完全に自動的に行われます。
設定管理¶
実稼働環境の品質を持つクラウドは設定とデプロイメントの自動化ツールを必ず使用しています。こうすることで、人的ミスをなくし、クラウドの迅速なスケールアウトが可能になります。自動化により、継続的な統合やテストが行いやすくなります。
OpenStack クラウドの構築時は、構成管理ツールまたはフレームワークを念頭に設計、実装に着手するように強く推奨します。構成管理により、OpenStack のように複雑なインフラストラクチャーの構築、管理、維持において陥りやすい多くの問題を回避することができます。構成管理ユーティリティに必要なマニフェスト、クックブック、テンプレートを作成することで、多くの文書や監督機関へのレポート要件を満たすことができます。さらに、構成管理は、ビジネス継続性計画 (BCP) および災害復旧 (DR) プランの一部としても機能する可能性もあります。その場合、DR やセキュリティ侵害が合った場合にノードやサービスを既知の状態へ再構築することができます。
Additionally, when combined with a version control system such as Git or
SVN, you can track changes to your environment over time and re-mediate
unauthorized changes that may occur. For example, a nova.conf
file or other configuration file falls out of compliance with your
standard, your configuration management tool can revert or replace the
file and bring your configuration back into a known state. Finally a
configuration management tool can also be used to deploy updates;
simplifying the security patch process. These tools have a broad range
of capabilities that are useful in this space. The key point for
securing your cloud is to choose a tool for configuration management and
use it.
There are many configuration management solutions; at the time of this writing there are two in the marketplace that are robust in their support of OpenStack environments: Chef and Puppet. A non-exhaustive listing of tools in this space is provided below:
Chef
Puppet
Salt Stack
Ansible
ポリシーの変更¶
ポリシーや構成管理が変更されると、そのアクティビティをロギングして、新しいセットのコピーをバックアップすると慣習として良いでしょう。通常、このようなポリシーや設定は Git などのバージョン管理リポジトリに保存されています。
セキュアなバックアップとリカバリ¶
It is important to include backup procedures and policies in the overall System Security Plan. For a good overview of OpenStack's Backup and Recovery capabilities and procedures, refer to the OpenStack Operations Guide on backup and recovery.
認証済みのユーザーおよびバックアップクライアントのみがバックアップサーバーにアクセスできるようにすること
バックアップの保存や送信にはデータ暗号化オプションを使用すること
セキュリティが強化された専用のバックアップサーバーを使用すること。バックアップサーバーのログは日次で監査し、ほんの一握りの人だけがこのログにアクセスできるようにしなければいけません。
データのリカバリーオプションを定期的にテストすること。セキュアなバックアップからリストアが可能なものの 1 つにイメージがあります。情報漏洩などが発生した場合のベストプラクティスは、すぐに実行中のインスタンスを終了して、セキュアなバックアップリポジトリにあるイメージからインスタンスを再起動することです。
セキュリティ監査ツール¶
セキュリティ監査ツールは、構成管理ツールを補完することができます。セキュリティ監査ツールは、セキュリティ制御の多くが指定のシステム設定を満たしていることを確認するプロセスを自動化します。これらのツールは、セキュリティ設定方針文書 (例: STIG および NSA ガイド) から個別のシステムインストール環境のギャップを埋めるサポートをします。例えば、SCAP は実行中のシステムと事前定義済みのプロファイルを比較することができます。SCAP はプロファイル内のどの制御に対応しているか、問題があるものはどれか、確認されていないものはどれかを詳細にまとめたレポートを出力します。
構成管理とセキュリティ監査ツールを組み合わせることで強力になります。監査ツールはデプロイメントの課題をハイライトし、構成管理ツールは各システムの変更プロセスを簡素化して監査の課題に対応していきます。このような方法で組み合わせて使用することで、これらのツールは、基本的なセキュリティの強化からコンプライアンスのバリデーションに至るまで、このようなセキュリティ要件を満たすクラウドを維持できるようにします。
構成管理およびセキュリティ監査ツールは、もう１つのレベルで複雑性をクラウドにもたらします。この複雑性により、新たなセキュリティの課題が出てきます。これについては、セキュリティの利点もあるため、許容範囲のリスクのトレードオフという見解を持っています。これらのツールの運用におけるセキュリティ確保については、本書の対象外となっています。
