クラウド・サービスのセキュリティー・ポリシーを作成する

目的、スコープ、背景、アクション、制限事項を基にクラウドのセキュリティー・ポリシーを作成する方法を学ぶ

望むと望まないとに関わらず、企業や政府機関が経済的な理由からデータ・センターで行っていた業務をクラウドに移行することは珍しくありません。彼らがクラウドでホスティングする手法を好まない理由は、信頼性とセキュリティーを懸念するからです。ビジネスのセキュリティーに関する懸念を緩和するためには、クラウドのセキュリティー・ポリシーを作成する必要があります。この記事では、ユーザーの管理、データの保護、そして仮想マシンのセキュリティーに関して、セキュリティー・ポリシーを作成する方法について説明します。

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。彼女は、『RFID in the Supply Chain』の著者であり、『Enterprise Systems Integration, Second Edition Handbook』の編集者でもあります。


developerWorks 貢献著者レベル

2011年 7月 22日

注意深く作成されたセキュリティー・ポリシーには、クラウド・コンピューティング・サービスのコンシューマーとプロバイダーが何をすべきかの概要が定められています。プロバイダーはセキュリティー・ポリシーを作成することで、管理に要する時間を大幅に削減することができます。

セキュリティー・ポリシーを構成する要素は以下の 4 つです。

  • どのようなクラウド・サービスがプロバイダーによってホストされるのか。それは SaaS (Software as a Service) なのか、PaaS (Platform as a Service) なのか、あるいは IaaS (Infrastructure as a Service) なのか。
  • パブリック・クラウドなのかプライベート・クラウドなのか。
  • ユーザーはオペレーティング・システム、ハードウェア、ソフトウェアをどの程度制御できるのか。
  • ユーザー、リソース、データ・リクエストに対するしきい値ポリシーをクラウド・サービスの各タイプにどう適用するのか。

他にも、ポリシーに影響を与える可能性がある要素として、以下の内容を考慮する必要があります。

  • 社内アプリケーションをクラウド内で完璧に動作させるために、先を見越した変更としてアプリケーションの動作をどう変更したか。
  • プロバイダーは組織管轄下のデータ・センターの社内部署なのか、それとも通信業界の企業が外部でホストしているプロバイダーなのか。
  • そのコンシューマーが属する業界の種類は広範にわたっているかどうか (小売業界、電気・ガス・水道などのエネルギー業界、金融業界、医療業界、石油化学業界など)。

セキュリティー・ポリシーを確認したいというコンシューマーの要求を満たすために、すべてのプロバイダーは (以前の記事で説明したしきい値ポリシーと同様に) セキュリティー・ポリシーをコンシューマーに提供する必要があります。プロバイダーはコンシューマーに対し、あるタイプのクラウド・サービスをコンシューマーがレンタルすなわちサブスクライブする前に、解決しておく必要がある、あるいは交渉する必要があると思われる、セキュリティー関連の質問を送るように働きかけなければなりません。

この記事ではまず、それぞれのクラウド・タイプごとにどのようなセキュリティーに重点が置かれているのかを説明します。次に、セキュリティー・ポリシーを作成する際に含める必要がある要素として、目的、スコープ、背景、アクション、制限事項のチェックリストを使用する例を紹介します。

どのようなセキュリティーに重点を置くのか、例を見る

クラウドのセキュリティー・ポリシーでは、ユーザーの管理、データの保護、仮想マシンのセキュリティーに重点を置きます。このセキュリティー・ポリシーは、デプロイされたアプリケーション、オペレーティング・システム、ハードウェア、ソフトウェア、ストレージ、ネットワーキングに対し、クラウドによって提供されるモデルの場合、コンシューマーがどの程度制御できるかに影響されます。

では、以下の簡単な 3 つのケースを見てみましょう。

ケース 1: SaaS でアクセスを管理する場合

最初のケースとして、SaaS のセキュリティー・ポリシーでは、コンシューマーが個人、企業、政府機関のいずれであるかによらず、コンシューマーがレンタルした特定のアプリケーションへのアクセスをどの程度管理できるかに重点が置かれます。アクセスの管理には、ID の盗難やなりすましのリスクを軽減することなどが含まれています。

SaaS で重点を置いているセキュリティーに影響する制御要素として、以下のようなものがあります。

  • SaaS のエンド・ユーザー: エンド・ユーザーが制御できるのは、デスクトップ・コンピューターやラップトップ・コンピューター、モバイル機器からプロバイダーのアプリケーションへのアクセスのみです。
  • SaaS のプロバイダー: 少なくとも、プロバイダーはオペレーティング・システム、ハードウェア、ネットワーク・インフラストラクチャー、アプリケーションのアップグレードおよびパッチを制御することができます。プロバイダーはユーザーしきい値レベルを設定することができます。

ケース 2: PaaS でデータを保護する場合

2 番目のケースとして、PaaS のセキュリティー・ポリシーでは、アプリケーションへのアクセスの管理に加え、データの保護に重点を置きます。データの保護には、PaaS がボットネットの操作を指揮する指令室 (CnC) としてマルウェア・アプリケーションのインストールに使用されるリスクを軽減することなどが含まれています。

PaaS で重点を置いているセキュリティーに影響する制御要素として、以下のようなものがあります。

  • PaaS アプリケーション開発者: 開発者は、独立系ソフトウェア・ベンダー (ISV) や、ベンチャー企業、大企業の部門によって作成、ホストされるすべてのアプリケーションのビジネス・ライフサイクル全体にわたり、そのアプリケーションを制御することができます。開発者は、例えばカスタムの小売管理アプリケーションをビルド、デプロイ、実行し、そのアプリケーションのすべての機能に対するアップグレードやパッチを管理します。そのアプリケーションのライフサイクルの一部として、開発者はスプレッドシート、ワード・プロセッサー、バックアップ、課金、給与処理、請求などの機能を使用します。
  • PaaS プロバイダー: 少なくとも、プロバイダーはオペレーティング・システム、ハードウェア、ネットワーク・インフラストラクチャー、リソース管理を制御することができます。プロバイダーは、ユーザー、リソース、データ・リクエストのしきい値レベルを設定することができます。

ケース 3: IaaS で仮想マシンを管理する場合

最後のケースとして、IaaS のセキュリティー・ポリシーでは、データ保護に加えて仮想マシンの管理、そして仮想マシンのベースにある従来のコンピューティング・リソースのインフラストラクチャーに対するユーザー・アクセスの管理に重点を置きます。仮想マシンの管理には、IaaS がボットネットの操作を指揮する指令室 (CnC) として仮想インフラストラクチャーへの悪意のあるアップデートに使用されるリスクを軽減することなどが含まれています。IaaS で重点を置いているセキュリティーに影響する制御要素として、以下のようなものがあります。

  • IaaS インフラストラクチャーおよびネットワークのスペシャリスト: このスペシャリストは、オペレーティング・システム、ネットワーク機器、デプロイされたアプリケーションを仮想マシン・レベルで制御することができます。インフラストラクチャーのスペシャリストは、仮想サーバーや仮想ストレージ領域ブロックをスケールアップまたはスケールダウンすることができます。
  • IaaS プロバイダー: 少なくとも、プロバイダーはクラウド環境内にある従来のコンピューティング・リソースのインフラストラクチャーを制御することができます。プロバイダーは、ユーザー、リソース、データ・リクエストのしきい値レベルを設定することができます。

チェックリストを作成する

どこから手を付ければよいかわからなくても、心配はありません。ここではセキュリティー・ポリシーに何を含めればよいかを確認するためのチェックリストを紹介します。では早速始めましょう。

以下に挙げるのが、この単純化したシナリオにおけるチェックリストの項目に関するヒントです。

  • 目的: ポリシーの目的を記述してください
  • スコープ: ポリシーの範囲を規定してください
  • 背景: ポリシーの背後にある情報を記述してください
  • アクション: 準備はできていますか?しっかりと準備をしてください
  • 制限事項: 制限事項を扱ってください

そのセキュリティー・ポリシーによって何をしようとしているのかを簡単に記述します。以下のようなテンプレートを使用すると、目的を記述する方法についての感覚をつかむことができます。

目的: ポリシーの目的を記述してください

このセキュリティー・ポリシーの目的は、以下に記載する各しきい値レベルを上げるように悪意を持って設計されたマルウェア・アプリケーションが、あるクラウド・サービスのタイプにインストールされるリスクを軽減することです。
  • リソースしきい値ポリシーによって最初から設定されているリソースしきい値レベル: リソースしきい値レベルが異常に高い場合、悪意のあるリソース・インスタンスによって、サービス・レベル・アグリーメント (SLA) で規定されているサービス可用性の保証レベルが変更されている可能性があります。リスクを軽減するための措置として、リソース・インスタンスのしきい値レベルの監視を検討する必要があります。
  • (ユーザー・ライセンスによる制限に基づき) ユーザーしきい値ポリシーによって最初から設定されている最大レベル: 最大レベルがユーザー数の制限を超えた場合、ハッカーや不満を持つ従業員が (実際には権限を持たないにもかかわらず) 権限を持ったユーザーのふりをしているのかもしれません。リスクを軽減するための措置として、人員の経歴チェックやユーザーのアクセス権の取り消しを検討する必要があります。
  • データ・リクエストしきい値ポリシーによって最初から設定されているデータ・リクエストしきい値レベル: しきい値レベルが異常に高い場合、キューにある大量のデータ・リクエストのバックアップ処理によって高いネットワーク・レイテンシーが発生する可能性があります。リスクを軽減するための措置として、データ・リクエストしきい値レベルの監視を検討する必要があります。

スコープ: ポリシーの範囲を規定してください

セキュリティー・ポリシーの適用範囲を明確にすることにより、スコープを定義します。その範囲の中で、どのタイプのクラウド・サービスをプロバイダーがホストし、コンシューマーがレンタルすなわちサブスクライブするのか、どんなしきい値ポリシーを適用するのか、そしてどのようにしてセキュリティー・ポリシーを適用するのかを規定します。

例えばプロバイダーが 3 つのタイプすべてのクラウド・サービスをホストする場合、プロバイダーは以下について明記する必要があります。

  • エンド・ユーザーは、ユーザーしきい値ポリシーで設定されたしきい値レベル内で特定のアプリケーションをレンタルするのかどうか。
  • アプリケーション開発者は PaaS のみをレンタルし、PaaS 上で実行する特定の SaaS アプリケーションのパラメーターをカスタマイズまたは変更するのかどうか。また PaaS はユーザー、リソース、データ・リクエストに対するしきい値ポリシーで設定されるしきい値レベルの範囲内なのかどうか。
  • アプリケーション開発者と、それらのアプリケーションを SaaS として利用するユーザーは、PaaS 上に併存する SaaS アプリケーションのサブスクリプションを購入できるのかどうか。また、それらの SaaS アプリケーションは 3 つのタイプのしきい値レベルすべての範囲内なのかどうか。
  • インフラストラクチャーやネットワークのスペシャリストは IaaS をレンタルして仮想インフラストラクチャー環境を構築し、その IaaS 上で PaaS を実行するのかどうか。またそれらの PaaS は 3 つのタイプのしきい値レベルすべての範囲内なのかどうか。

上記 4 つの各シナリオで、プロバイダーは、コンシューマーのアクティビティーがセキュリティー・ポリシーの範囲内に収まっているかどうか (アクセス制御、データ保護、仮想マシン管理に関するセキュリティー・ポリシーの条項に従っているかどうか) を確認する必要があります。セキュリティー・ポリシーの条項に従うことに合意した後でコンシューマーがポリシーに規定されている範囲を超えるアクティビティーを行った場合、コンシューマーはポリシー違反のリスクをおかすことになります。その場合には、プロバイダーはポリシーに従わない場合の結果を示すことで、コンシューマーのアクティビティーをポリシーの範囲内に収めさせる必要があります。

スコープを記述するためのテンプレートとして、以下を使用することができます。

このポリシーは、SaaS を利用するエンド・ユーザー、PaaS を利用するアプリケーション開発者、IaaS を利用するインフラストラクチャーおよびネットワークのアーキテクトのすべてに適用されます。すべてのエンド・ユーザー、開発者、アーキテクトは、アクセス制御、データ保護、仮想マシン管理に関するセキュリティー・ポリシーのすべての条項に同意し、このセキュリティー・ポリシーに関するすべての契約条件を遵守することに同意します。このポリシー、あるいは関連する他の IT ポリシーや規制に違反する行為を行ったすべてのエンド・ユーザー、開発者、ネットワーク・アーキテクトは、このプロバイダーによるサービスの制限あるいは打ち切りの対象となります。

背景: ポリシーの背後にある情報を記述してください

コンシューマーが最初に知りたがることは、プロバイダーは社内のプロバイダーなのか社外のプロバイダーなのか、プロバイダーとコンシューマーとの間の制御の管理の境界はどこなのか (例えば、SaaS のエンド・ユーザーはほとんど何も制御できない、など)、プロバイダーがどのようにしてアクセス制御の管理や、データの保護、仮想マシンの管理を行い、クラウドのセキュリティーに対する攻撃やインシデントにどう対応するのか、といった点です。

次にコンシューマーが知りたがることは、SaaS、PaaS、IaaS のユーザー、リソース、データ・リクエストに対するしきい値ポリシーで、どのようなセキュリティーが重視されるか、ということです。またコンシューマーは、しきい値レベルと (SLA で規定される) サービス可用性の保証レベルとがどう関係するかも知りたがります。

クリスマス商戦のケース (「先を見越したしきい値ポリシーをクラウドに設定する」を参照) では、リソース・インスタンスの使用量がしきい値レベルを超えるまでに急増し、システムによって追加のリソース・インスタンスが作成されてクラウド内のワークロード要求のバランスが動的に取られる様子をコンシューマーは目にします。このような対応を実現するには、同時に処理することができるユーザー数とデータ・リクエスト数を増やす一方で、セキュリティーを高める必要があります。

次にコンシューマーは、システムに発生した予期せぬ問題によってパフォーマンスが低下し、ユーザー、リソース、データ・リクエストのしきい値レベルが、しきい値ポリシーに最初に設定された条件を満たさなくなることに気付きます。あるいは、コンシューマーは、ビジネス・タスクの処理中あるいはアプリケーションの開発中に、クラウド (そしてしきい値レベル) に障害が発生したことや、クラウドが攻撃にさらされたことに気付きます。そして遅まきながら、マルウェア・アプリケーションをインストールするためのボットネットの操作を指揮する司令室としてクラウドが使用されていたことに気付きます。

いずれの場合も、コンシューマーは、セキュリティー・ポリシーがシステム (そしてしきい値レベル) の回復についてどこまでカバーしているのか、また SLA の規定に従って割引、一定期間の支払い免除、あるいは解約の権利の取得がどの程度早く実現されるのかを知りたがります。

以下のようなテンプレートを使用すると、何を含めればよいかの感覚をつかむことができます。

クラウド・サービス・プロバイダーは、通信業界の一員である IBM によって外部でホストされています。

ワークロード要求や、同時に処理する必要があるユーザー数およびデータ・リクエスト数が、しきい値レベルを超えるまでに急増したことによって、システムのパフォーマンスが保証レベルである 30 日間の可用性よりも低下した場合には、プロバイダーは SLA の規定に従い、コンシューマーに対し、割引、一定期間の支払い免除、サービス解約の権利を与える必要があります。プロバイダーはセキュリティー・ポリシーの例外や制限事項について、コンシューマーに通知しなければなりません。

ユーザー・ライセンスには、以下の 3 種類の最大数が規定されています。

  • アプリケーションに同時にアクセスできるユーザーの数
  • 各ユーザーに割り当てられるリソース・インスタンスの数
  • ワークロード要求が急増した際に処理することが可能なデータ・リクエストの数

アクション: しっかりと準備をしてください

ここでは、コンシューマーを満足させるために、以下の 10 項目のアクションを行うことを提言します。

  • アクション #1: セキュリティー・ポリシーのコピーをコンシューマーに送ります。そうすることで、コンシューマーはクラウド・サービスに契約する前にセキュリティー・ポリシーを検討することができ、また疑問を解決することができます。
  • アクション #2: SaaS ユーザー・ライセンスの中に、同時にアクセスできるユーザー、それらのユーザー用のリソース・インスタンス数、そして同時に処理できるデータ・リクエストの数に関する最大数の制限を明記します。
  • アクション #3: リソース、ユーザー、データ・リクエストに対するしきい値ポリシーの中で、しきい値レベルとサービス可用性の保証レベルについて言及します。
  • アクション #4: SaaS クラウドで現在実行されているアプリケーションを置き換える目的で、データ・センターで開発されたアプリケーションに対し、先を見越した動作変更が計画されている場合、その変更についての通知をコンシューマーに送ります。
  • アクション #5: クラウドには毎日 24 時間アクセスできるのか、それとも通常の営業時間内なのかを明記します。
  • アクション #6: PaaS を利用するアプリケーション開発者と、そのアプリケーションを SaaS として使用するユーザーに対し、その PaaS 上に併存する SaaS アプリケーションをサブスクライブすることを許可します。
  • アクション #7: クラウドを使用する予定のユーザーにクラウドへのアクセスを許可する前に、それらのユーザー全員の経歴チェックを要求します。どの程度詳細に経歴チェックをするかは、クラウド・サービスのタイプや、パブリック・クラウドなのかプライベート・クラウドなのか、そしてクラウドを使用する予定のユーザーが属する業界の種類などに依存します。
  • アクション #8: 承認されたクラウド・ユーザーとなるための、セキュリティー意識、データの命名法および扱い方に関するトレーニング・プログラムの実施を要求します。
  • アクション #9: クラウド・ユーザー、特に PaaS のクラウド・ユーザーに役割を割り当てる際、役割が異なれば任務も異なることを保証するように要求します。
  • アクション #10: ユーザー・アクセス管理、データ保護技術、仮想マシンに対するメンテナンスやアップグレードが予定されている場合、それについて事前に注意を促します。

以下のようなテンプレートを使用することができます。

セキュリティー・トレーニング: プロバイダーは承認されたクラウド・ユーザーとなるためのセキュリティー・トレーニングの最低要件を設定し、セキュリティー意識を高め、データの命名法や扱い方を理解させます。

事前に通知されたメンテナンス: プロバイダーはユーザー・アクセス管理、データ保護技術、仮想マシンなどのアップグレードをはじめとする、メンテナンスのスケジュールを設定します。

サービスの可用性: プロバイダーは、通常の営業時間におけるクラウドへのアクセスの可用性を設定します。

サービスの併存: プロバイダーは PaaS 上に併存する SaaS アプリケーションに対する要件を設定します。

ユーザーしきい値ポリシー: プロバイダーは、同時アクセスできる最大ユーザー数を下回る値にユーザーしきい値レベルを設定します。このポリシーには、同時アクセスできるユーザー数と、それらのユーザーが利用できるリソース・インスタンスの数とが比例関係にあることと、ユーザーしきい値ポリシーがセキュリティー・ポリシーの一部であることを明記する必要があります。

経歴チェック: プロバイダーは、クラウドを使用する予定のユーザーに対する経歴チェックの要件を規定する必要があります。

SaaS ユーザー・ライセンス: プロバイダーは以下の数に対して最大値を設定します。

  • アプリケーションに同時にアクセスできるユーザーの数
  • ユーザーがアプリケーションにアクセスして実行する際に使用できるリソース・インスタンスの数
  • 利用可能なリソース・インスタンスを使用してユーザーが同時に送受信できるデータ・リクエストの数

制限事項: 制限事項を扱ってください

ほとんどの場合、何らかの制限事項があるものです。例えば次のような制限事項が考えられます。

  • サービスの優先度の問題: 組織がコンシューマーに割り当てた役割により、コンシューマーのグループが異なると優先度も異なる場合があります。SaaS アプリケーションにアクセスする上で、管理者権限を持つエンド・ユーザーは管理者権限を持たないエンド・ユーザーよりも高い優先度を持ちます。
  • 管理ガバナンス・グループの変更: あらゆる変更を反映するために、セキュリティー・ポリシー、しきい値ポリシー、そして SLA を更新する必要があります。
  • クラウド・サービスのタイプに対する例外: 以下にヒントを記載します。例外の例として、プロバイダーが直接制御できる範囲外で光ファイバーが誤って切断された場合や、事前に通知されたメンテナンス (不定期および定期)、そして事前に通知された (先を見越した) アプリケーションのアップグレードなどが挙げられます。
  • セキュリティー・ポリシーに関する契約条件のいずれかを遵守しなかった場合のセキュリティー・ペナルティー: セキュリティー・ポリシーや IT ポリシーの規制に従わなかった場合の結果を規定しておきます。

以下のようなテンプレートを使用することができます。

SaaS のユーザー・ライセンスを管理するエンド・ユーザーは、ライセンスされたアプリケーションにアクセスする上で、他のエンド・ユーザーよりも高い優先度を持ちます。

最近の組織変更により、ポリシー・ガバナンス・グループは FGH 部門から RST 部門に異動しました。そのため、セキュリティー・ポリシー、しきい値ポリシー、そして SLA を更新する必要があります。

サービスの例外として現在認められている事項は以下のとおりです。

  • 事前に通知された、アプリケーションの動作に対する先を見越した変更やアップグレード
  • プロバイダーのホストがボットネットから攻撃を受けた場合
  • プロバイダーによる、事前に通知されたメンテナンス
  • プロバイダーのサービスを通常どおり利用できるのは午前 7 時から午後 6 時まで、サービスの利用が制限されるのは午後 8 時から午後 11 時まで

まとめ

セキュリティー・ポリシーを作成するためには、事前に計画を立て、ポリシーの目的、スコープ、背景をどう記述するかという問題を解決する必要があります。開発者はクラウド・サービスのコンシューマーとプロバイダーの両方と話し合い、コンシューマーが制御できる範囲をどの程度にする必要があるか、プロバイダーはどのようなアクションを実行する必要があるか、ポリシーに対する制限事項として何があるか、といった問題を検討する必要があります。最も重要なことは、コンシューマーはプロバイダーからセキュリティー・ポリシーを (そしてしきい値ポリシーも) 入手して内容を確認し、解決すべき疑問点を整理してからプロバイダーと交渉することです。

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmartCloud Enterprise で利用可能な製品イメージを調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=733191
ArticleTitle=クラウド・サービスのセキュリティー・ポリシーを作成する
publish-date=07222011