クラウドネイティブ アプリの Azure セキュリティ

クラウドネイティブ アプリケーションは、従来のアプリケーションよりも簡単でセキュリティ保護が困難な場合があります。 欠点として、より小さなアプリケーションをセキュリティで保護し、セキュリティ インフラストラクチャを構築するためのエネルギーを増やす必要があります。 ほとんどのサービス展開におけるプログラミング言語とスタイルの異種の性質は、多くの異なるプロバイダーからのセキュリティ情報にさらに注意を払う必要もあることも意味します。

逆に、それぞれが独自のデータ ストアを持つ小規模なサービスによって、攻撃の範囲が制限されます。 攻撃者が 1 つのシステムを侵害した場合、モノリシック アプリケーションの場合よりも、攻撃者が別のシステムにジャンプすることはおそらく困難です。 プロセス境界は強力な境界です。 また、データベースのバックアップが公開された場合、そのデータベースにはデータのサブセットのみが含まれており、個人データが含まれる可能性は低く、損害はより制限されます。

脅威のモデリング

利点がクラウドネイティブ アプリケーションの欠点を上回る場合でも、同じ包括的なセキュリティの考え方に従う必要があります。 セキュリティと安全な思考は、開発と運用のストーリーのすべてのステップの一部である必要があります。 アプリケーションを計画するときは、次のような質問をします。

• このデータが失われる影響は何ですか?
• このサービスに挿入される不適切なデータによる損害を制限するにはどうすればよいですか?
• 誰がこのデータにアクセスする必要がありますか?
• 開発とリリースのプロセスに関する監査ポリシーはありますか?

これらすべての質問は、 脅威モデリングと呼ばれるプロセスの一部です。 このプロセスは、システムに対する脅威、脅威の可能性、およびそれらの潜在的な損害に関する質問に答えようとします。

脅威の一覧が確立されたら、軽減する価値があるかどうかを判断する必要があります。 場合によっては、脅威を計画する可能性が非常に低く、コストがかかるため、それにエネルギーを費やす価値はありません。 たとえば、状態レベルのアクターによっては、何百万ものデバイスで使用されるプロセスの設計に変更が挿入される可能性があります。 ここで、 リング 3 で特定のコードを実行する代わりに、そのコードはリング 0 で実行されます。 このプロセスにより、ハイパーバイザーをバイパスし、ベア メタル マシンで攻撃コードを実行できる悪用が可能になり、そのハードウェアで実行されているすべての仮想マシンに対する攻撃が可能になります。

変更されたプロセッサは、そのプロセッサのシリコン設計に関する顕微鏡と高度な知識がなければ検出が困難です。 このシナリオは発生する可能性が低く、軽減にコストがかかるため、脅威モデルでは悪用防止の構築が推奨されない可能性があります。

「インクリメント攻撃 (Id が URL 内の Id=2 に置き換えられる) や SQL インジェクションを許可するようなアクセス制御の脆弱性など、より発生しやすい脅威は、対策を構築するための魅力的な対象です。」 これらの脅威の軽減策は、会社の評判を汚す恥ずかしいセキュリティ ホールを構築して防ぐのに非常に合理的です。

最小限の特権の原則

コンピューターのセキュリティに関する考え方の 1 つは、最小特権 (POLP) の原則です。 実際には、デジタルまたは物理的なセキュリティのほとんどの形式で基本的な考え方です。 要するに、原則は、すべてのユーザーまたはプロセスが、そのタスクを実行できる最小数の権限を持つ必要があるということです。

たとえば、銀行の窓口を考えてみましょう。金庫にアクセスすることは珍しいアクティビティです。 そのため、平均的な窓口係は金庫を開けることができない。 アクセスを取得するには、追加のセキュリティ チェックを実行する銀行マネージャーを通じて要求をエスカレートする必要があります。

コンピューター システムでは、データベースに接続するユーザーの権限がすばらしい例です。 多くの場合、データベース構造の構築とアプリケーションの実行の両方に使用される単一のユーザー アカウントがあります。 極端なケースを除き、アプリケーションを実行しているアカウントはスキーマ情報を更新する必要はありません。 さまざまなレベルの特権を提供する複数のアカウントが必要です。 アプリケーションでは、テーブル内のデータへの読み取りと書き込みのアクセスを許可するアクセス許可レベルのみを使用する必要があります。 この種の保護により、データベース テーブルの削除や悪意のあるトリガーの導入を目的とした攻撃が排除されます。

クラウドネイティブ アプリケーションの構築のほぼすべての部分で、最小限の特権の原則を覚えておくメリットがあります。 ロールベースのアクセス制御 (RBAC) でファイアウォール、ネットワーク セキュリティ グループ、ロール、スコープを設定する際に、それを見つけることができます。

侵入テスト

アプリケーションが複雑になるにつれて、攻撃ベクトルの数は驚くべき速度で増加します。 脅威モデリングには、システムを構築するのと同じユーザーによって実行される傾向があるという欠陥があります。 多くの開発者がユーザー操作を想定し、使用できないユーザー インターフェイスを構築する際に問題が発生するのと同じように、ほとんどの開発者はすべての攻撃ベクトルを見るのが困難です。 また、システムを構築する開発者が攻撃手法に精通せず、重要な情報を見逃している可能性もあります。

侵入テストまたは "ペン テスト" では、システムを攻撃しようとする外部アクターを取り込みます。 これらの攻撃者は、外部のコンサルティング会社や、ビジネスの別の部分からの優れたセキュリティ知識を持つ他の開発者である可能性があります。 システムを覆そうとする試みのために無制限の自由が与えられる。 多くの場合、パッチを適用する必要がある広範なセキュリティ ホールが見つかります。 場合によっては、攻撃ベクトルは、CEO に対するフィッシング攻撃を悪用するようなまったく予期しないものです。

Azure 自体は、Microsoft 内のハッカーチームからの攻撃を常に受けています。 長年にわたり、彼らは何十もの致命的な攻撃ベクトルを見つけた最初の人で、外部から悪用される前にそれらを閉じています。 ターゲットの誘惑が高いほど、外部アクターがそれを悪用しようとする可能性が高くなり、世界には Azure よりも魅力的なターゲットはほとんどありません。

モニタリング

攻撃者がアプリケーションに侵入しようとすると、その警告が表示されます。 多くの場合、サービスからのログを調べることで攻撃を見つけることができます。 攻撃は成功する前に発見できる兆候を残します。 たとえば、攻撃者がパスワードを推測しようとすると、ログイン システムに対して多数の要求が行われます。 ログイン システムを監視すると、一般的なアクセス パターンと一線を越えた奇妙なパターンを検出できます。 この監視は、何らかの対策を有効にするように運用担当者に警告できるアラートに変えることができます。 成熟度の高い監視システムでは、これらの偏差に基づいて、要求をブロックしたり応答を調整したりするルールを事前に追加してアクションを実行する場合もあります。

ビルドを安全に保護する

セキュリティが見過ごされることが多い場所の 1 つは、ビルド プロセスの周りにあります。 ビルドでセキュリティ チェック (セキュリティ保護されていないコードのスキャンやチェックインされた資格情報など) を実行する必要があるだけでなく、ビルド自体もセキュリティで保護する必要があります。 ビルド サーバーが侵害された場合、製品に任意のコードを導入するための素晴らしいベクトルが提供されます。

攻撃者が Web アプリケーションにサインインするユーザーのパスワードを盗もうとしているとします。 チェックアウトされたコードを変更して、ログイン要求を別のサーバーにミラーリングするビルド ステップを導入できます。 次にコードがビルドを通過すると、自動的に更新されます。 ソース コードの脆弱性スキャンでは、ビルド前に実行されるため、この脆弱性はキャッチされません。 同様に、ビルド ステップはビルド サーバー上で実行されるため、コード レビューでは誰もキャッチしません。 悪用されたコードは、パスワードを収集できる運用環境に移行します。 ビルド プロセスの変更の監査ログが存在しないか、少なくとも誰も監査を監視していない可能性があります。

このシナリオは、システムへの侵入に使用できる一見低い値のターゲットの完全な例です。 攻撃者がシステムの境界を侵害したら、アクセス許可を好きな場所で本当の損害を引き起こす可能性のある時点まで昇格させる方法を見つける作業を開始できます。

セキュリティで保護されたコードの構築

.NET Framework は既に非常に安全なフレームワークです。 配列の末尾から離れるなど、アンマネージ コードの落とし穴の一部を回避します。 検出されたセキュリティ ホールを修正するために、作業は積極的に行われます。 バグ 報奨金プログラム もあります。このプログラムは、研究者に支払ってフレームワーク内の問題を見つけ、それらを悪用するのではなく報告します。

.NET コードの安全性を高める方法は多数あります。 .NET のセキュリティで保護されたコーディングガイドラインなどのガイドラインに従うのは、コードが一から安全であることを確認するための妥当な手順です。 OWASP トップ 10 は、セキュリティで保護されたコードを構築するためのもう 1 つの貴重なガイドです。

ビルド プロセスは、運用環境に移行する前に、ソース コードの問題を検出するためのスキャン ツールを配置するのに適した場所です。 ほとんどのプロジェクトには、他のパッケージへの依存関係があります。 古いパッケージをスキャンできるツールは、夜間のビルドで問題をキャッチします。 Docker イメージをビルドする場合でも、基本イメージに既知の脆弱性がないことを確認して確認すると便利です。 もう 1 つ確認する必要があるのは、誰も誤って資格情報をチェックインしていないということです。

組み込みのセキュリティ

Azure は、ほとんどのユーザーの使いやすさとセキュリティのバランスを取るために設計されています。 ユーザーによってセキュリティ要件が異なるので、クラウド セキュリティに対するアプローチを微調整する必要があります。 Microsoft は、 セキュリティ センターで大量のセキュリティ情報を公開しています。 このリソースは、組み込みの攻撃軽減テクノロジのしくみを理解したい専門家が最初に参照すべきものです。

Azure Portal 内では、 Azure Advisor は常に環境をスキャンし、推奨事項を作成するシステムです。 これらの推奨事項の一部はユーザーのコストを節約するように設計されていますが、仮想ネットワークによって保護されていないストレージ コンテナーを世界中に公開するなど、セキュリティで保護されていない可能性のある構成を特定するように設計されているものもあります。

Azure ネットワーク インフラストラクチャ

オンプレミスのデプロイ環境では、ネットワークの設定に大きなエネルギーが必要です。 ルータ、スイッチなどを設定するのは複雑な作業です。 ネットワークを使用すると、特定のリソースが他のリソースと通信し、場合によってはアクセスを防ぐことができます。 多くの場合、ネットワーク規則は、開発環境から運用環境へのアクセスを制限します。これは、開発途中のコードが誤作動し、大量のデータを削除するという不測の事態を防ぐためです。

ほとんどの PaaS Azure リソースには、最も基本的で制限の少ないネットワーク設定のみが用意されています。 たとえば、インターネット上の誰でもアプリ サービスにアクセスできます。 通常、新しい SQL Server インスタンスは制限されるため、外部関係者はアクセスできませんが、Azure 自体で使用される IP アドレス範囲は許可されます。 そのため、SQL サーバーは外部の脅威から保護されていますが、攻撃者は Azure 上のすべての SQL インスタンスに対して攻撃を開始できる場所から Azure ブリッジヘッドを設定するだけで済みます。

さいわい、ほとんどの Azure リソースは、きめ細かいアクセス制御を可能にする Azure Virtual Network に配置できます。 オンプレミス ネットワークが、より広い世界から保護されているプライベート ネットワークを確立する方法と同様に、仮想ネットワークは Azure ネットワーク内にあるプライベート IP アドレスのアイランドです。

図 9-1 Azure の仮想ネットワーク。

オンプレミス ネットワークにネットワークへのアクセスを制御するファイアウォールがあるのと同じ方法で、仮想ネットワークの境界で同様のファイアウォールを確立できます。 既定では、仮想ネットワーク上のすべてのリソースは引き続きインターネットと通信できます。 何らかの形式の明示的なファイアウォール例外を必要とする着信接続のみです。

ネットワークが確立されると、ストレージ アカウントなどの内部リソースは、仮想ネットワーク上にあるリソースからのアクセスのみを許可するように設定できます。 このファイアウォールは、追加レベルのセキュリティを提供します。そのストレージ アカウントのキーが漏洩した場合、攻撃者はそれに接続して漏洩したキーを悪用できなくなります。 このシナリオは、最小特権の原則のもう 1 つの例です。

Azure Kubernetes クラスター内のノードは、Azure にネイティブな他のリソースと同様に、仮想ネットワークに参加できます。 この機能は、 Azure Container Networking Interface と呼ばれます。 実際には、仮想マシンとコンテナー イメージが割り当てられる仮想ネットワーク内にサブネットが割り当てられます。

仮想ネットワーク内のすべてのリソースが他のすべてのリソースと通信する必要があるわけではありませんが、最小限の特権の原則を示すパスを続行します。 たとえば、ストレージ アカウントと SQL データベースに対して Web API を提供するアプリケーションでは、データベースとストレージ アカウントが相互に通信する必要はほとんどありません。 それらの間のデータ共有は、Web アプリケーションを経由します。 そのため、 ネットワーク セキュリティ グループ (NSG) を使用して、2 つのサービス間のトラフィックを拒否できます。

リソース間の通信を拒否するポリシーは、特にトラフィック制限なしで Azure を使用する背景から来て実装するのが面倒な場合があります。 他の一部のクラウドでは、ネットワーク セキュリティ グループの概念がはるかに普及しています。 たとえば、AWS の既定のポリシーは、NSG のルールによって有効になるまでリソース間で通信できないことです。 この開発には時間がかかりますが、より制限の厳しい環境では、より安全な既定値が提供されます。 適切な DevOps プラクティス (特に Azure Resource Manager または Terraform を使用してアクセス許可を管理する) を使用すると、ルールの制御が容易になります。

仮想ネットワークは、オンプレミスリソースとクラウド リソース間の通信を設定する場合にも役立ちます。 仮想プライベート ネットワークを使用して、2 つのネットワークをシームレスに接続できます。 この方法では、すべてのユーザーがオンサイトに存在するシナリオでは、ゲートウェイを使用せずに仮想ネットワークを実行できます。 このネットワークを確立するために使用できるテクノロジは多数あります。 最も簡単なのは、多くのルーターと Azure の間で確立できる サイト間 VPN を使用することです。 トラフィックは、インターネット経由で暗号化され、他のトラフィックと同じバイトあたりのコストでトンネリングされます。 より多くの帯域幅以上のセキュリティが望ましいシナリオでは、Azure では、オンプレミス ネットワークと Azure の間のプライベート回線を使用する Express Route というサービスが提供されます。 よりコストがかかり、確立が困難ですが、セキュリティも強化されます。

Azure リソースへのアクセスを制限するためのロールベースのアクセス制御

RBAC は、Azure で実行されているアプリケーションに ID を提供するシステムです。 アプリケーションは、キーやパスワードの代わりに、または使用するだけでなく、この ID を使用してリソースにアクセスできます。

セキュリティ プリンシパル

RBAC の最初のコンポーネントはセキュリティ プリンシパルです。 セキュリティ プリンシパルには、ユーザー、グループ、サービス プリンシパル、またはマネージド ID を指定できます。

図 9-2 さまざまな種類のセキュリティ プリンシパル。

• ユーザー - Azure Active Directory にアカウントを持つすべてのユーザーがユーザーです。
• グループ - Azure Active Directory からのユーザーのコレクション。 グループのメンバーとして、ユーザーは自分のロールに加えて、そのグループのロールを引き受ける。
• サービス プリンシパル - サービスまたはアプリケーションが実行されるセキュリティ ID。
• マネージド ID - Azure によって管理される Azure Active Directory ID。 マネージド ID は、通常、Azure サービスに対する認証用の資格情報を管理するクラウド アプリケーションを開発するときに使用されます。

セキュリティ プリンシパルは、ほとんどのリソースに適用できます。 この側面は、Azure Kubernetes 内で実行されているコンテナーにセキュリティ プリンシパルを割り当て、Key Vault に格納されているシークレットにアクセスできるようにすることを意味します。 Azure 関数は、Active Directory インスタンスと通信して、呼び出し元ユーザーの JWT を検証できるアクセス許可を取得できます。 サービス プリンシパルを使用してサービスを有効にすると、ロールとスコープを使用してアクセス許可を細かく管理できます。

役割

セキュリティ プリンシパルは、多くの役割を担ったり、よりサルトリアルな類推を使用して多くの帽子を着用したりすることができます。 各ロールは、"Azure Service Bus エンドポイントからメッセージを読み取る" などの一連のアクセス許可を定義します。 セキュリティ プリンシパルの有効なアクセス許可セットは、セキュリティ プリンシパルが持つすべてのロールに割り当てられているすべてのアクセス許可の組み合わせです。 Azure には多数の組み込みロールがあり、ユーザーは独自のロールを定義できます。

図 9-3 RBAC ロールの定義。

Azure に組み込まれているのは、所有者、共同作成者、閲覧者、ユーザー アカウント管理者など、多くの高レベルのロールでもあります。 所有者ロールを使用すると、セキュリティ プリンシパルはすべてのリソースにアクセスし、アクセス許可を他のユーザーに割り当てることができます。 共同作成者はすべてのリソースに同じレベルのアクセス権を持っていますが、アクセス許可を割り当てることはできません。 閲覧者は既存の Azure リソースのみを表示でき、ユーザー アカウント管理者は Azure リソースへのアクセスを管理できます。

DNS ゾーン共同作成者などのより詳細な組み込みロールには、1 つのサービスに制限された権限があります。 セキュリティ プリンシパルは、任意の数のロールを引き受けることができます。

スコープ

ロールは、Azure 内の制限付きリソース セットに適用できます。 たとえば、前の Service Bus キューからの読み取りの例にスコープを適用すると、アクセス許可を 1 つのキューに絞り込むことができます。"Azure Service Bus エンドポイントからメッセージを読み取 blah.servicebus.windows.net/queue1"

スコープは、1 つのリソースと同じくらい狭くすることも、リソース グループ全体、サブスクリプション、さらには管理グループに適用することもできます。

セキュリティ プリンシパルに特定のアクセス許可があるかどうかをテストする場合、ロールとスコープの組み合わせが考慮されます。 この組み合わせにより、強力な承認メカニズムが提供されます。

否定する

以前は、RBAC に対して "許可" ルールのみが許可されていました。 この動作により、一部のスコープのビルドが複雑になりました。 たとえば、ストレージ アカウントの無限のリストに明示的なアクセス許可を付与する必要がある場合を除き、すべてのストレージ アカウントへのセキュリティ プリンシパル アクセスを許可します。 新しいストレージ アカウントが作成されるたびに、このアカウントの一覧に追加する必要があります。 これにより、管理オーバーヘッドが増え、望ましくないことが確かに増えました。

拒否規則は、許可規則よりも優先されます。 現在、同じ「ただ一つを除いてすべてを許可する」スコープは、「すべてを許可する」と「この特定の一つを拒否する」の2つのルールとして表現できます。 拒否ルールは、管理を容易にするだけでなく、すべてのユーザーへのアクセスを拒否することで、より安全なリソースを許可します。

アクセスの確認

ご想像のとおり、多数のロールとスコープを持つことで、サービス プリンシパルの有効なアクセス許可を把握することは非常に困難になる可能性があります。 その上に拒否ルールを重ねると、複雑さが増すだけです。 幸いなことに、任意のサービス プリンシパルの有効なアクセス許可を表示できるアクセス 許可計算ツール があります。 これは通常、図 9-3 に示すように、ポータルの [IAM] タブにあります。

図 9-4 アプリ サービスのアクセス許可計算ツール。

秘密保護

パスワードと証明書は、攻撃者にとって一般的な攻撃ベクトルです。 パスワードクラッキング ハードウェアはブルート フォース攻撃を実行し、1 秒あたり数十億のパスワードを推測しようとする可能性があります。 そのため、リソースへのアクセスに使用されるパスワードは、さまざまな文字で強力である必要があります。 これらのパスワードは、覚えることができないようなパスワードの種類です。 幸いなことに、Azure のパスワードは、実際には人間が知る必要はありません。

多くのセキュリティ 専門家は、 パスワード マネージャーを使用して独自のパスワードを保持することが最善のアプローチであることを示唆しています。 パスワードは 1 か所で一元化されますが、非常に複雑なパスワードを使用して、アカウントごとに一意であることを確認することもできます。 同じシステムが Azure 内に存在します。シークレットの中央ストアです。

Azure Key Vault

Azure Key Vault には、データベース、API キー、証明書などのパスワードを格納するための一元的な場所が用意されています。 シークレットがコンテナーに入力されると、シークレットは再び表示されることはなく、それを抽出して表示するコマンドは意図的に複雑になります。 セーフボックス内の情報は、ソフトウェア暗号化または FIPS 140-2 レベル 2 で検証されたハードウェア セキュリティ モジュールを使用して保護されます。

キー コンテナーへのアクセスは、RBAC を介して提供されます。つまり、任意のユーザーがコンテナー内の情報にアクセスできるだけではありません。 たとえば、Web アプリケーションが Azure Key Vault に格納されているデータベース接続文字列にアクセスしたいとします。 アクセスを取得するには、アプリケーションをサービス プリンシパルを使用して実行する必要があります。 この役割を演じることで、金庫から秘密を読み取ることができます。 さまざまなセキュリティ設定があり、アプリケーションがコンテナーに対して持つアクセスをさらに制限できるため、シークレットは更新できませんが、読み取りのみを行うことができます。

キー コンテナーへのアクセスを監視して、想定されるアプリケーションのみがコンテナーにアクセスしていることを確認できます。 ログを Azure Monitor に統合し直すことができるので、予期しない状況が発生したときにアラートを設定できます。

Kubernetes

Kubernetes 内には、シークレット情報の小さな部分を維持するための同様のサービスがあります。 Kubernetes シークレットは、一般的な kubectl 実行可能ファイルを使用して設定できます。

シークレットの作成は、格納する値の base64 バージョンを見つけるのと同じくらい簡単です。

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

次に、次の例のような secret.yml という名前のシークレット ファイルに追加します。

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

最後に、次のコマンドを実行して、このファイルを Kubernetes に読み込むことができます。

kubectl apply -f ./secret.yaml

これらのシークレットは、ボリュームにマウントすることも、環境変数を介してコンテナー プロセスに公開することもできます。 アプリケーションを構築するための 12 要素アプリ アプローチでは、最も低い共通分母を使用して設定をアプリケーションに送信することが提案されています。 環境変数は、オペレーティング システムやアプリケーションに関係なくサポートされるため、最も低い共通分母です。

組み込みの Kubernetes シークレットを使用する代わりに、Kubernetes 内から Azure Key Vault 内のシークレットにアクセスすることもできます。 これを行う最も簡単な方法は、シークレットを読み込もうとしているコンテナーに RBAC ロールを割り当てることです。 その後、アプリケーションは Azure Key Vault API を使用してシークレットにアクセスできます。 ただし、この方法ではコードを変更する必要があり、環境変数を使用するパターンには従いません。 代わりに、コンテナーに値を挿入できます。 この方法は、クラスター上のユーザーがアクセスできるため、実際には Kubernetes シークレットを直接使用するよりも安全です。

通信時および待機時の暗号化

データを安全に保つことは、ディスク上にあるか、さまざまなサービス間を通過しているかに関係なく重要です。 データが漏洩しないようにする最も効果的な方法は、他のユーザーが簡単に読むことができない形式に暗号化することです。 Azure では、さまざまな暗号化オプションがサポートされています。

輸送中

Azure のネットワーク上のトラフィックを暗号化するには、いくつかの方法があります。 通常、Azure サービスへのアクセスは、トランスポート層セキュリティ (TLS) を使用する接続経由で行われます。 たとえば、Azure API へのすべての接続には TLS 接続が必要です。 同様に、Azure Storage 内のエンドポイントへの接続は、TLS で暗号化された接続でのみ機能するように制限できます。

TLS は複雑なプロトコルであり、接続が TLS を使用していることを知るだけでは、セキュリティを確保するには不十分です。 たとえば、TLS 1.0 は慢性的に安全ではなく、TLS 1.1 はあまり優れた機能ではありません。 TLS のバージョン内でも、接続の暗号化解除を容易にするさまざまな設定があります。 最善の措置は、サーバー接続が up-to-date と適切に構成されたプロトコルを使用しているかどうかを確認することです。

このチェックは、SSL ラボの SSL サーバー テストなどの外部サービスによって実行できます。 一般的な Azure エンドポイント (この場合はサービス バス エンドポイント) に対してテストを実行すると、ほぼ完全なスコアの A が生成されます。

Azure SQL データベースなどのサービスでも、TLS 暗号化を使用してデータを非表示に保ちます。 TLS を使用して転送中のデータを暗号化することに関する興味深い点は、Microsoft が TLS を実行しているコンピューター間の接続をリッスンできないということです。 これにより、データが Microsoft 自体や標準的な攻撃者よりも多くのリソースを持つ国家主体の脅威にさらされる可能性を懸念する企業に安心感を提供することが期待されています。

図 9-5. Service Bus エンドポイントのスコア A を示す SSL ラボ レポート。

このレベルの暗号化は常に十分ではありませんが、Azure TLS 接続が非常に安全であるという確信を得る必要があります。 Azure は、暗号化の向上に伴い、セキュリティ標準を引き続き進化させます。 セキュリティ標準を監視し、Azure の改善に合った更新を行っている人がいることを知って良いですね。

保存中

どのアプリケーションでも、データがディスク上に置かれている場所が多数あります。 アプリケーション コード自体は、いくつかのストレージ メカニズムから読み込まれます。 また、ほとんどのアプリケーションでは、SQL Server、Cosmos DB、驚くほど価格効率の高い Table Storage など、何らかの種類のデータベースも使用されます。 これらのデータベースはすべて、頻繁に暗号化されたストレージを使用して、適切なアクセス許可を持つアプリケーション以外のユーザーがデータを読み取れないようにします。 システム演算子でも、暗号化されたデータを読み取ることはできません。 そのため、顧客は自分の機密情報が秘密のままであると確信できます。

ストレージ

Azure の大部分の基盤となるのは、Azure Storage エンジンです。 仮想マシン ディスクは、Azure Storage の上にマウントされます。 Azure Kubernetes Service は、それ自体が Azure Storage でホストされている仮想マシン上で実行されます。 Azure Functions Apps や Azure Container Instances などのサーバーレス テクノロジでも、Azure Storage の一部であるディスクが不足します。

Azure Storage が適切に暗号化されている場合は、他のほとんどのものも暗号化するための基盤が提供されます。 Azure Storage は、FIPS 140-2 準拠の256 ビット AES で暗号化されます。 これは、過去 20 年ほどにわたって広範な学術調査の対象となっている、よく評価されている暗号化テクノロジです。 現時点では、キーを知らない人が AES によって暗号化されたデータを読み取ることを可能にする既知の実用的な攻撃はありません。

既定では、Azure Storage の暗号化に使用されるキーは Microsoft によって管理されます。 これらのキーへの悪意のあるアクセスを防ぐために、広範な保護が実施されています。 ただし、特定の暗号化要件を持つユーザーは、Azure Key Vault で管理される 独自のストレージ キーを提供 することもできます。 これらのキーはいつでも取り消すことができ、取り消された場合、それらを使用しているストレージ アカウントの内容にアクセスすることができなくなります。

仮想マシンは暗号化されたストレージを使用しますが、Windows の BitLocker や Linux 上の DM-Crypt などのテクノロジを使用して、別の暗号化レイヤーを提供できます。 これらのテクノロジは、ディスク イメージがストレージからリークされた場合でも、読み取り不可能なままであることを意味します。

Azure SQL

Azure SQL でホストされているデータベースでは、 Transparent Data Encryption (TDE) と呼ばれるテクノロジを使用して、データが暗号化されたままになります。 新しく作成されたすべての SQL データベースでは既定で有効になっていますが、レガシ データベースでは手動で有効にする必要があります。 TDE は、データベースだけでなく、バックアップとトランザクション ログの暗号化と暗号化解除をリアルタイムで実行します。

暗号化パラメーターは、 master データベースに格納され、起動時に残りの操作のためにメモリに読み込まれます。 つまり、 master データベースは暗号化されていない状態を維持する必要があります。 実際のキーは Microsoft によって管理されます。 ただし、厳密なセキュリティ要件を持つユーザーは、Azure Storage の場合とほぼ同じ方法で Key Vault に独自のキーを提供できます。 Key Vault は、キーのローテーションや失効などのサービスを提供します。

TDS の "透過的" 部分は、暗号化されたデータベースを使用するためにクライアントの変更が必要ないという事実から生まれます。 この方法は優れたセキュリティを提供しますが、ユーザーがデータの暗号化を解除するには、データベース パスワードを漏えいするだけで十分です。 データベース内の個々の列またはテーブルを暗号化するもう 1 つの方法があります。 Always Encrypted を使用すると、暗号化されたデータがデータベース内のプレーン テキストに表示されなくなります。

このレベルの暗号化を設定するには、SQL Server Management Studio のウィザードを使用して、暗号化の種類と、関連付けられているキーを格納する Key Vault 内の場所を選択する必要があります。

図 9-6 Always Encrypted を使用して暗号化するテーブル内の列を選択する。

これらの暗号化された列から情報を読み取るクライアント アプリケーションでは、暗号化されたデータを読み取るために特別な制限を設ける必要があります。 接続文字列は Column Encryption Setting=Enabled で更新する必要があり、クライアント資格情報は Key Vault から取得する必要があります。 その後、SQL Server クライアントに列暗号化キーを準備する必要があります。 これが完了すると、残りのアクションでは SQL クライアントへの標準インターフェイスが使用されます。 つまり、SQL クライアント上に構築された Dapper や Entity Framework などのツールは、変更なしで引き続き機能します。 すべての言語で、すべての SQL Server ドライバーで Always Encrypted をまだ使用できない場合があります。

TDE と Always Encrypted の両方をクライアント固有のキーと共に使用できるため、最も厳密な暗号化要件もサポートされます。

Cosmos DB（コスモス DB）

Cosmos DB は、Microsoft が Azure で提供する最新のデータベースです。 セキュリティと暗号化を念頭に置いて、ゼロから構築されています。 AES-256 ビット暗号化は、すべての Cosmos DB データベースの標準であり、無効にすることはできません。 通信の TLS 1.2 要件と組み合わせて、ストレージ ソリューション全体が暗号化されます。

図 9-7 Cosmos DB 内のデータ暗号化のフロー。

Cosmos DB では、顧客の暗号化キーを提供する機能はありませんが、チームは、それなしで PCI-DSS 準拠し続けるために重要な作業を行っています。 Cosmos DB では、Azure SQL の Always Encrypted と同様の種類の単一列暗号化もまだサポートされていません。

セキュリティを維持する

Azure には、安全性の高い製品をリリースするために必要なすべてのツールがあります。 ただし、鎖の強さは最も弱い部分にかかっています。 Azure 上にデプロイされたアプリケーションが適切なセキュリティの考え方と適切なセキュリティ監査を使用して開発されていない場合、それらはチェーンの弱いリンクになります。 多数の優れた静的分析ツール、暗号化ライブラリ、およびセキュリティ プラクティスを使用して、Azure にインストールされているソフトウェアが Azure 自体と同じくらい安全であることを確認できます。 たとえば、 静的分析ツール や 暗号化ライブラリなどがあります。