はじめに
本記事では OCI Security Zones についてまとめていきます。
概要
簡潔に言うと、予防的統制を実現できるサービス です。
具体的に言うと、セキュリティポリシーを指定のコンパートメントに適用し、セキュリティリスクのあるリソースの作成及び操作を制限することができます。
OCI Security Zones を構成するコンポーネントを見ていきましょう。
セキュリティ・ゾーン
対象とするコンパートメントとセキュリティ・ゾーン・レシピとの関連付けを表すものです。
指定したコンパートメントとその子コンパートメント全てがセキュリティ・ゾーンとして扱われます。
加えて、後述するセキュリティ・ゾーン・レシピは、アタッチしたコンパートメントとその子コンパートメント全てに継承されます。
そのため、異なるセキュリティ・ゾーン・レシピを適用したいコンパートメントがある場合は、そのコンパートメントを対象とするセキュリティ・ゾーンを別途作成する必要があります。
もしくは以下ドキュメントの通りセキュリティ・ゾーンから指定のコンパートメントを削除することでも対応は可能です。
セキュリティ・ゾーン・レシピ
セキュリティ・ゾーンとして扱われるコンパートメントにアタッチするセキュリティ・ゾーン・ポリシーの集合体です。
セキュリティ・ゾーンとして扱われるコンパートメント内のリソース作成及び操作は、セキュリティ・ゾーン・ポリシーにより制限されます。
レシピには オラクルが定義する Maximum Security Recipe と ユーザーが定義する Custom Security Recipe があります。
Maximum Security Recipe に含まれるセキュリティ・ゾーン・ポリシーは以下ドキュメントを参照してみてください。
Maximum Security Recipe 内のセキュリティ・ゾーン・ポリシーの無効化はできません。
そのため、一部のセキュリティ・ゾーン・ポリシーを無効化したい場合は、Maximum Security Recipe をクローンして作成する Custom Security Recipe を利用しましょう。
セキュリティ・ゾーン・ターゲット
セキュリティ・ゾーンを作成した際に自動で作成される、指定したコンパートメントを対象とした OCI Cloud Guard ターゲットのことです。
使用方法(デモ)
検証構成
検証構成図は以下の通りです。
検証では、以下２パターンの動作を確認していきます。
- 親コンパートメントを対象とするセキュリティ・ゾーンを作成し
Maximum Security Recipeをアタッチ。子コンパートメントでセキュリティ違反となるリソース作成を実施 - 追加で子コンパートメントを対象とするセキュリティ・ゾーンを作成し、パターン１で違反となったポリシーを無効化した
Custom Security Recipeをアタッチ。子コンパートメントで同様のリソース作成を実施
- 環境コードは以下 GitHub にあげてますので、よかったら覗いてみてください
OCI Cloud Guard 有効化
OCI Security Zones は OCI Cloud Guard と統合されているため、セキュリティ・ゾーンを作成するには OCI Cloud Guard が有効化されている必要があります。
今回有効化については割愛しますが、以下ドキュメントを参考にしてみてください。
OCI Cloud Guard 用IAMポリシー作成と、OCI Cloud Guard が有効化されればOKです。
OCI Cloud Guard ターゲットは作成しても問題有りませんが、セキュリティ・ゾーンとして指定するコンパートメントとターゲットとして指定したコンパートメントが一致する場合、そのターゲットは削除されます。
パターン１
子コンパートメントにもセキュリティ・ゾーン・レシピが継承されることを確認していきます。
セキュリティ・ゾーン作成
OCI コンソール左上のハンバーガーマークをクリックし、Identity & Security → Zones をクリックします。
Create Security Zone をクリックします。
- OCI Cloud Guard が有効化されていないと上記画面は表示されません
対象とするコンパートメントはルートコンパートメントとし、セキュリティ・ゾーン・レシピは Oracle-managed (Maximum Security Recipe) として Create Security Zone をクリックします。
- 上記画像の注意書きにもある通り、既存の OCI Cloud Guard ターゲットは置き換えられると示されています
これで作成は完了です。
ちなみに OCI Cloud Guard のターゲット一覧を確認すると、セキュリティ・ゾーン作成時に指定したコンパートメントを対象とするターゲットが自動で作成されています。
こちらの画面からのセキュリティ・ゾーン・レシピ変更はできませんが、ディテクタ・レシピ等は変更可能です。
動作確認
セキュリティ・ゾーン・ポリシーの一部である deny buckets_without_vault_key に違反する操作を、子コンパートメントで実施していきます。
オブジェクトストレージサービス画面にて、子コンパートメントが選択されている状態で Create bucket をクリックします。
全てデフォルトのままで Create bucket をクリックします。
ポイントは Encryption がオラクルマネージドになっていることです。
すると顧客管理キーで暗号化してねとエラーになりました。
しっかり子コンパートメントにもセキュリティ・ゾーン・レシピが継承されているのがわかります。
パターン２
別途アタッチされたセキュリティ・ゾーン・レシピが優先されることを確認していきます。
カスタムセキュリティ・ゾーン・レシピ作成
こちら でも触れた通り Maximum Security Recipe 内のセキュリティ・ゾーン・ポリシーを無効化することができないため、カスタムセキュリティ・ゾーン・レシピを作成していきます。
OCI Security Zones サービスページ内の Recipes を選択し Create Recipe をクリックします。
レシピ名及び説明文を入力し Next をクリックします。
所属させるコンパートメントは今回ルートコンパートメントにしていますが、子コンパートメントでもOKです。
デフォルトでは全てのポリシーが有効化になっているので、パターン１で引っ掛かった deny buckets_without_vault_key のチェックを外して Next をクリックします。
- ポリシーの有効化・無効化は後からでも可能です
確認画面が表示されるので Create をクリックして完了です。
セキュリティ・ゾーン作成
子コンパートメントを対象とするセキュリティ・ゾーンを作成していきます。
対象コンパートメントが選択された状態で Create Security Zone をクリックします。
先程作成したセキュリティ・ゾーン・レシピを選択し、対象コンパートメントを選択し、Create Security Zone をクリックします。
これで作成は完了です。
こちらも OCI Cloud Guard のターゲット一覧を確認すると、セキュリティ・ゾーン作成時に指定したコンパートメントを対象とするターゲットが自動で作成されています。
動作確認
パターン１と同様の操作を実施してみます。
オブジェクトストレージサービス画面にて、子コンパートメントが選択されている状態で Create bucket をクリックします。
全てデフォルトのままで Create bucket をクリックします。
今度は問題なく作成ができました。
別途アタッチしたセキュリティ・ゾーン・レシピが優先されていることが確認できます。
おわりに
本記事では、セキュアなコンパートメントを構成するのに役立つサービスである OCI Security Zones についてまとめました。
無償で利用可能なサービス ですし、セキュリティベストプラクティスを用意に実現できるため、運用コストとの兼ね合いですが積極的に有効化していきましょう。
🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。