セキュリティ境界と脅威

クラウドとは、セキュリティドメインと呼ばれる、機能やユーザー、共有セキュリティの懸念点に基づいた論理コンポーネントの集まりであると要約できます。脅威に関するアクターやベクトルは、リソースへのアクセスや動機をベースに分類されます。OpenStack の目標は、リスクや脆弱性保護の目的にあわせてドメインごとにセキュリティの懸念点に関する判断材料を提供することです。

セキュリティドメイン

A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization (AuthN/Z) requirements and users.

これらのドメインをさらに分類する場合もありますが (該当箇所で説明)、一般的に OpenStack クラウドをセキュアにデプロイしていく上で最低限必要な部分を構成する、4 つの異なるセキュリティドメインのことを指します。以下に、これらのセキュリティドメインを示しています。

1. パブリック

2. ゲスト

3. 管理

4. データ

We selected these security domains because they can be mapped independently or combined to represent the majority of the possible areas of trust within a given OpenStack deployment. For example, some deployment topologies may consist of a combination of guest and data domains onto one physical network while other topologies have these domains separated. In each case, the cloud operator should be aware of the appropriate security concerns. Security domains should be mapped out against your specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid.

パブリック

パブリックのセキュリティドメインとは、クラウドインフラストラクチャーの中で完全に信頼できないエリアのことです。インターネット全体を指す場合や、単に権限を持たないネットワークを指す場合があります。機密性や完全性の要件を持つデータがこのドメインを通過する場合には、補完コントロールを使用してこのデータを保護する必要があります。

このドメインは常に*信頼できない*と考えなければなりません。

ゲスト

ゲストのセキュリティドメインは、Compute のインスタンス間通信に通常使用されますが、API の呼び出しなどクラウドのオペレーションをサポートするサービスではなく、クラウド上のインスタンスが生成する Compute データを処理します。

Public and private cloud providers that do not have stringent controls on instance use or allow unrestricted internet access to VMs should consider this domain to be untrusted. Private cloud providers may want to consider this network as internal and trusted only if the proper controls are implemented to assert that the instances and all associated tenants are to be trusted.

管理

管理セキュリティドメインは、サービスがやりとりをする場所です。このドメインは時に「コントロールプレーン」と呼ばれることもあり、このドメイン内のネットワークは設定パラメーター、ユーザー名、パスワードなどの機密データを送信します。コマンドやコントロールトラフィックは通常このドメインに常駐し、完全性に関する強い要件が必要となります。このドメインへのアクセスについては非常に制限されたものでなくてはならず、さらに監視も必要です。また、このセキュリティドメインでは、本ガイドで記載されているセキュリティのベストプラクティスすべてを採用するようにしてください。

In most deployments this domain is considered trusted. However, when considering an OpenStack deployment, there are many systems that bridge this domain with others, potentially reducing the level of trust you can place on this domain. See セキュリティドメインのブリッジ for more information.

データ

The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. Most of the data transmitted across this network requires high levels of integrity and confidentiality. In some cases, depending on the type of deployment there may also be strong availability requirements.

このネットワークの信頼レベルは、デプロイメントの意思決定により左右されるため、デフォルトの信頼レベルは割り当てていません。

セキュリティドメインのブリッジ

A bridge is a component that exists inside more than one security domain. Any component that bridges security domains with different trust levels or authentication requirements must be carefully configured. These bridges are often the weak points in network architecture. A bridge should always be configured to meet the security requirements of the highest trust level of any of the domains it is bridging. In many cases the security controls for bridges should be a primary concern due to the likelihood of attack.

上記の図は、データドメインと管理ドメインをブリッジするコンピュートノードです。このように、コンピュートノードは管理ドメインのセキュリティ要件に見合うように設定する必要があります。同様に、この図の API エンドポイントは信頼できないパブリックドメインと管理ドメインをブリッジしており、パブリックドメインから管理ドメインに伝搬しないように攻撃から保護されるように設定する必要があります。

デプロイ担当者は、ブリッジするどのドメインよりも高い基準でブリッジのセキュリティを確保するように考えるようにしてください。API エンドポイントの上記の例では、攻撃者はパブリックドメインから API エンドポイントをターゲットにして、情報漏洩や管理ドメインへアクセス権の獲得を期待しつつこのエンドポイントを利用するのです。

OpenStack のデザインではセキュリティドメインの分離が困難です。コアサービスは通常少なくとも 2 つのドメインをブリッジしているため、ドメインのセキュリティ制御を適用する場合、細心の注意を払う必要があります。

脅威の分類、アクター、攻撃ベクトル

クラウドデプロイメントの種類の多く (パブリックまたはプライベート) は、なんらかの攻撃にさらされています。本章では、攻撃者を分類して、各セキュリティドメインで考えられる攻撃の種類をまとめていきます。

脅威のアクター

脅威のアクターとは、防御の対象となりえる攻撃者のクラスを抽象的に表したものです。アクターの技術が高くなるにつれ、攻撃の軽減や防止を成功させるために必要なセキュリティ制御にかかるコストが嵩みます。セキュリティはコスト、使いやすさ、防御の間でのトレードオフということになります。ここで記載した脅威のアクターすべてから、クラウドのデプロイメントを保護することはできません。OpenStack クラウドをデプロイする方は、デプロイメントと用途の間でバランスが確保できるポイントを決定する必要が出てきます。

インテリジェントなサービス

このガイドでは最も有能な攻撃者とされています。情報機関やその他の国家主体は、ターゲットに圧力をかけるために莫大なリソースを費やすことができます。他のどのアクターよりも能力があります。人、技術両方の面で非常に厳しい制御がないと、これらのアクターから防御することは極めて困難です。

重大組織犯罪

極めて有能で金銭で動く攻撃者グループ。エクスポロイと開発やターゲットのリサーチに対する資金を組織内で調達できます。最近、ロシアンビジネスネットワーク (RBN) などの組織が登場し、大規模なサイバー犯罪企業がサイバー攻撃がどのようにして商品として成り立ったかを証明しました。産業スパイ活動は、SOC グループに分類されます。

非常に有能な組織

これは通常ビジネスから資金を調達しているのではありませんが、サービスプロバイダーやクラウドオペレーターに対して重大な脅威をもたらす可能性のある「ハクティビスト」タイプの組織のことを指します。

動機のある個人

一人で行動するこれらの攻撃者は、詐欺師または悪意のある従業員、不満を持った顧客、小規模の産業スパイなど多くのものに扮して攻撃します。

スクリプトキディー

自動化された脆弱性のスキャンやエクスプロイト。非標的型の攻撃。単なるいたずらの場合が多く、上記のアクターのいずれかによる情報漏洩により組織の評判に大きなリスクを与えます。

パブリッククラウドとプライベートクラウドの考慮点

Private clouds are typically deployed by enterprises or institutions inside their networks and behind their firewalls. Enterprises will have strict policies on what data is allowed to exit their network and may even have different clouds for specific purposes. Users of a private cloud are typically employees of the organization that owns the cloud and are able to be held accountable for their actions. Employees often attend training sessions before accessing the cloud and will likely take part in regularly scheduled security awareness training. Public clouds by contrast cannot make any assertions about their users, cloud use-cases or user motivations. This immediately pushes the guest security domain into a completely untrusted state for public cloud providers.

パブリッククラウドの攻撃対象領域での顕著な相違点は、サービスに対してインターネットアクセスを提供しなければならない点です。API エンドポイントやダッシュボードなど、インスタンスの接続性、インターネット経由でのファイルアクセス、クラウド制御のファブリックとの対話機能は、パブリッククラウドで必須アイテムなのです。

Privacy concerns for public and private cloud users are typically diametrically opposed. The data generated and stored in private clouds is normally owned by the operator of the cloud, who is able to deploy technologies such as data loss prevention (DLP) protection, file inspection, deep packet inspection and prescriptive firewalling. In contrast, privacy is one of the primary barriers for the adoption of public cloud infrastructures, as many of the previously mentioned controls do not exist.

アウトバウンド攻撃とレピュテーションリスク

クラウドデプロイメントからアウトバウンド方向で起こりえる不正使用に対して、十分な配慮が必要です。パブリックでも、プライベートでも、クラウドは多くのリソースが使用出来る状態になっている傾向にあります。悪意のある従業員など、ハッキングや与えられているアクセス権限のいずれかによりクラウド内に攻撃ポイントを設定した攻撃者は、これらのリソースにインターネット全体の負荷をかけることができます。コンピュートサービスがあるクラウドは、理想的な DDoS や総当り攻撃エンジンを作り出します。パブリッククラウドのユーザーは多くの場合、責任を負う必要がなく、自由に使用できるインスタンスをすぐにアウトバウンドの攻撃として作り出すことができるため、パブリッククラウドにとっては、この点はより差し迫った課題でしょう。悪意のあるソフトウェアをホストしたり、他のネットワークへ攻撃していたりしたことが判明すると、企業の評判に大きな打撃を与えることでしょう。防止の方法には、egress セキュリティグループ、アウトバウンドトラフィックの検査、顧客の教育・認識、詐欺や悪用軽減戦略などがあります。

攻撃の種類

以下の図は、前項で説明したアクターから出される可能性のある攻撃の種類を記載しています。このような図では常に例外が存在することに注意してください。

攻撃の種類

攻撃の形式ごとの規範的な防御については、本書の対象範囲外となっています。上記の図は、対策を行うべき脅威の種類、脅威のアクターについて詳細な情報を得た状態で意思決定ができるように支援します。商業的なパブリッククラウドのデプロイに関しては重大な犯罪の防止などが含まれる場合があります。 政府で使用するプライベートクラウドをデプロイする方は、細心の注意を払って設置された対策施設やサプライチェーンなど、より厳密な保護メカニズムを設置する必要があります。反対に、基本的なデプロイメントやテスト環境を設定する方は、制御に関する制約が少なくて済むでしょう。