X

A blog about Oracle Technology Network Japan

Maximum Security Zonesで、クラウドのセキュリティ対策の弱体化を防ぐ

Guest Author

※本記事は、Paul Toal (DISTINGUISHED SOLUTION ENGINEER - CYBER SECURITY)による"Prevent a weak cloud security posture with Maximum Security Zones"を翻訳したものです。


2019年9月、Oracle Cloud Infrastructure(OCI)エンジニアリングのExecutive Vice Presidentを務めるClay MagouyrkがOracle OpenWorldに登壇し、「エンタープライズ級のセキュリティがシンプルであるべき」理由と、「最大限のセキュリティを簡単に確保する」方法について語りました。同時に、そのビジョンを実現するために用意された、Oracle Cloud GuardMaximum Security Zonesなどの多数の機能を発表しました。これらの新しいサービスはすでに、提供が開始されています

 

2つの新サービスは、エンタープライズのワークロードを実行するのに理想とされる、もっとも安全なクラウドを実現するというオラクルのビジョンを具現化するにあたっての重要なマイルストーンです。2つのサービスは補い合って、予防と検知の両方を管理し、クラウド環境を守ります。Maximum Security Zonesは予防面をコントロールし、ユーザーが実装について不適切な判断を下すのを阻止して、セキュリティ対策が弱体化しないようにします。問題発生を予防できない場合は、検知と修正を制御するCloud Guardが、セキュリティ対策の弱点を突き止め、自動で修正します。Cloud Guardについては過去に、こちらこちらで記事を公開しています。そのようなわけで本日の記事では、Maximum Security Zonesに注目してみたいと思います。

では、課題を把握するところから始めましょう。新しいプロジェクトを開始し、新しいソリューションを作成しようとするときには、以下のような実にさまざまなソースから、ベスト・プラクティスに関する多数の情報を入手できます。

  • ベンダーの推奨事項
  • 組織としての標準とポリシー
  • 外部のフレームワーク
  • 規制準拠
  • リファレンス・アーキテクチャ

こうしたベスト・プラクティスは通常、認証、暗号化、ストレージ、アクセス制御など、さまざまなセキュリティの項目を広くカバーしています。とはいえ、多くの場合、ベスト・プラクティスに関するアドバイスは無視されるものです。プロジェクトのスケジュール、予算の制限、知識の差、環境(開始時は非本番環境)などあらゆる要素によって、関連度の高いベスト・プラクティスが実行されないために、環境のセキュリティが保たれず、セキュリティ対策が弱くなるのを、私たちは幾度となく目にしてきました。

OCI内で使用される新しいMaximum Security Zonesサービスによって、このリスクを最低限に留めることができます。セキュリティ・ゾーンというのは予防的な制御であり、機密性の高いデータやリソースが含まれるという性質を持っているために、制限が多くなる仕様になっています。たとえば、Maximum Security Zonesは、最大限のセキュリティ・ポリシーが有効にされた状態でリリースされます。したがって、パブリック・アクセスを許可すべきではない、機密データはできる限りインターネットから切り離す、という方針が採用されます。セキュリティ・ポリシーで、ポリシーに違反する可能性のあるリソースをユーザーが作成できないようにリアルタイムで阻止することによって、その方針を運用します。

Oracle Cloud Infrastructureに詳しくない読者のために説明しておくと、OCI内のリソース、つまりコンピュート・インスタンス、ネットワーク、ストレージなどは、論理的にグループ化されて複数のコンパートメントに分かれており、それぞれに異なるアクセス制御を適用できます(予算管理やコストの追跡なども同様です)。たとえば、私がコンパートメントAの管理者で、その中にある特定のリソース・セットの管理をしているとします。しかし私は、他のコンパートメントのリソースには一切アクセスできません。なぜこのような話をしたかと言うと、セキュリティ・ゾーンとはそもそも、セキュリティ・ゾーン・ポリシーが適用された特殊なコンパートメントだからです。セキュリティ・ゾーンが作成されると、コントロール・プレーンで操作がリアルタイムに監視され、セキュリティ・ポリシーに違反する操作はブロックされます。

Maximum Security Zonesでは、複数のポリシーがあらかじめ定義されており、レシピと呼ばれています(Cloud Guardと同じ呼び方です)。最初のリリースでは、このレシピによって最大限のセキュリティ保護が適用されます。これはもっとも制限の厳しいポリシーで、変更できません。将来的には、最大限のセキュリティに調整を加えたいお客様向けに、このポリシーをカスタマイズしたバージョンを作成できるようになります。次のスクリーンショットは、最大限のセキュリティ・レシピ内のポリシーの一部です。

 

新しいセキュリティ・ゾーンを作成すると、すべてのポリシーが一括して、リアルタイムで適用されます。次の例では、セキュリティ・ゾーン内で、新しいパブリック・サブネットが作成されようとしています。

 

リソースの作成時だけでなく、セキュリティ対策を弱める可能性のある操作が実行されるときにも必ず、チェックが行われます。たとえば次の図のように、オブジェクト・ストレージ・バケットから、カスタマーマネージド・キーの割当てを解除しようとする場合などです。

 

分かりやすくするために、簡単な例で考えてみましょう。次の図では、インターネットベースのアプリケーションが展開されています。ここにはロードバランサがあり、アプリケーションを実行する2つのサーバーと接続されています。また、バックエンドのデータベースと、オブジェクト・ストレージもいくらかあります。お分かりのとおり、この基本設計にはいくつも問題があります。

 

セキュリティ・ゾーンを使うと、この構成はどのように変わるでしょうか。次の図はその一例です。

 

セキュリティ・ゾーンに関すること以外にも、いくつかの設計上の選択がなされています。

  1. インターネットに接続されているコンポーネントをバックエンドから切り離す。その場合、サブネットとセキュリティ・リストを使用するだけではなく、Local Peering Gatewayで接続された独自の仮想クラウド・ネットワーク内に、コンパートメントを完全に隔離する。
  2. Webアプリケーション・ファイアウォールを追加してロードバランサ、ひいてはWebアプリケーションを保護する。
  3. Autonomous DatabaseとObject Storageを、プライベートIPアドレスのみで使用できるようにする。
  4. すべてのブロック、ブート、オブジェクト・ストレージについて、オラクルマネージド・キーから、カスタマーマネージドの暗号化キーに変更する。

それでは、セキュリティ・ゾーンはここでどのような役割を果たすのでしょうか。上の図で、赤いボックスで囲まれているセキュリティ・ゾーンでは、セキュアな構成が適用されています。適用されているポリシーには、以下のようなものがあります。

  1. すべてのコンピュート・インスタンスは、そこで使用されているストレージを暗号化するために、カスタマーマネージド・キーを使用して作成されていなければならない。
  2. オブジェクト・ストレージ・バケットは、暗号化のためにカスタマーマネージド・キーを使用して作成されていなければならない。
  3. どのカスタマーマネージド・キーも、ストレージ・リソースのいずれかから割当て解除することはできない。すなわち、オラクルマネージド・キーを再び使用することはできない。
  4. オブジェクト・ストレージ・バケットは公開できない。
  5. Autonomous DatabaseはプライベートIPアドレスで作成されていなければならず、パブリックIPアドレスを割り当てることはできない。
  6. すべての仮想マシンはプライベートIPアドレスで作成されていなければならず、パブリックIPアドレスを割り当てることはできない。
  7. すべての仮想マシンはオラクルが提供するプラットフォーム・イメージで作成されていなければならない。
  8. サブネットはプライベートでなければならず、パブリック・サブネットを作成することはできない。
  9. セキュリティ・ゾーンのブロック・ボリュームとブート・ボリュームは、セキュリティ・ゾーン外のコンピュート・インスタンスに接続することはできない。

ポリシーはこれだけではありません。用意されているポリシー全体を確認する場合は、Maximum Security Zonesのドキュメントをご覧ください。

セキュリティ・ゾーンが実際にどのように使用されるのかを知りたい方は、下の画像をクリックしてください。セキュリティ・ゾーンの簡単なユースケースを4つご紹介するデモを見ることができます。

 

上記のデモをご覧になると分かることですが、Maximum Security Zonesは数多くのチェックを実施するため、リソースを作成する管理者は、安全性に問題があるさまざまな操作がチェックされ、ブロックされるたびに、多数の違反メッセージを目にすることになります。そのため、ユーザー・エクスペリエンスに優れているとは言い難いだけではなく、経験の少ない管理者にとっては、そうしたメッセージが混乱のもととなるかもしれません。

この問題に対応するため、また「セキュリティを簡単に」というオラクルのビジョンをMaximum Security Zonesによってさらに推し進めるために、オラクルはOCI Security Advisorもご用意しました。これはコンピュート・リソースなどのリソースの作成時に使用できるガイド付きのフローをお客様にご提供するもので、お客様は最初から安全な構成で、そうしたリソースを作成できます。

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.