クラウドネイティブ アプリ向けの Azure のセキュリティ
ヒント
このコンテンツは eBook の「Azure 向けクラウド ネイティブ .NET アプリケーションの設計」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。
クラウドネイティブ アプリケーションは、従来のアプリケーションに比べてセキュリティで保護するのが簡単でもあり、難しくもあります。 欠点としては、より小規模なアプリケーションをセキュリティで保護する必要があり、セキュリティ インフラストラクチャの構築により多くのエネルギーを費やす必要があります。 また、ほとんどのサービスのデプロイでは、プログラミング言語とスタイルが異種混合であるため、さまざまなプロバイダーからのセキュリティ情報にさらに注意を払う必要があります。
一方で、小規模なサービスの場合、それぞれが独自のデータ ストアを持っているため、攻撃のスコープが限定されます。 攻撃者が 1 つのシステムを侵害した場合、その攻撃者が別のシステムも侵害することは、おそらくモノリシック アプリケーションの場合よりも難しくなるでしょう。 プロセスの境界は強力な境界です。 また、データベースのバックアップが漏えいしたとしても、そのデータベースにはデータのサブセットしか含まれておらず、個人情報が含まれている可能性は低いため、被害はより限定的です。
脅威モデリング
クラウドネイティブ アプリケーションの利点が欠点を上回っていても、同じように全体的なセキュリティの考え方に従う必要があります。 セキュリティと安全な考え方は、開発と運用のストーリーのすべての手順に含める必要があります。 アプリケーションを計画するときは、次のような項目を自問してください。
- このデータが失われた場合、どのような影響がありますか?
- 不正なデータがこのサービスに挿入された場合の損害を抑えるにはどうすればよいですか?
- 誰がこのデータにアクセスできる必要がありますか?
- 開発とリリースのプロセスに関する監査ポリシーはありますか?
このような質問はすべて、脅威モデリングと呼ばれるプロセスの一部です。 これは、システムにどのような脅威があるのか、脅威の可能性はどの程度か、脅威による潜在的な損害はどの程度か、という質問に答えを出そうと試みるプロセスです。
脅威の一覧を作成したら、それらを軽減する価値があるかどうかを判断する必要があります。 場合によっては、脅威の可能性が低く、それに対する計画にコストがかかるため、エネルギーを費やす価値がないこともあります。 たとえば、一部の国家レベルのアクターは、何百万台ものデバイスに使用されるプロセスの設計に変更を加える可能性があります。 このような状況で、あるコードがリング 3 で実行されるのではなく、そのコードがリング 0 で実行されるようになります。 このプロセスにより、ハイパーバイザーをバイパスして攻撃コードをベアメタル マシン上で実行する悪用が可能になり、そのハードウェア上で動作するすべての仮想マシンへの攻撃が可能になります。
変更されたプロセッサを検出するには、顕微鏡とそのプロセッサのシリコン上の設計に関する高度な知識が必要です。 このシナリオは発生する可能性が低く、軽減にもコストがかかるため、そのための悪用対策の構築を推奨する脅威モデルはないでしょう。
より可能性の高い脅威としては、Id の増分攻撃 (URL の Id=2 を Id=3 に置き換える) や SQL インジェクションを可能にするアクセス制御の破損などがあり、その防御策を構築する方が魅力的です。 このような脅威に対する軽減策を講じて、企業の評判を落とすような恥ずかしいセキュリティ ホールを防ぐことは非常に合理的です。
最小限の特権の原則
コンピューター セキュリティの基礎となる考え方の 1 つに、最小限の特権の原則 (POLP) があります。 これは、デジタル、物理を問わず、あらゆる形式のセキュリティにおいて基礎となる考え方です。 簡単に言うと、ユーザーまたはプロセスには、そのタスクを実行するために必要な最小限の数の権限を持たせるべきであるという原則です。
たとえば、銀行の窓口係を考えてみましょう。金庫を利用することは珍しい行動です。 そのため、平均的な窓口係が自分で金庫を開けることはできません。 アクセス権を得るには、追加のセキュリティ チェックを行う銀行のマネージャーを介して要求をエスカレートする必要があります。
コンピューター システムの場合、データベースに接続するユーザーの権限がその好例です。 多くの場合、データベース構造の構築とアプリケーションの実行の両方に 1 つのユーザー アカウントが使用されます。 極端な場合を除いて、アプリケーションを実行するアカウントは、スキーマ情報を更新できる必要がありません。 さまざまなレベルの特権を付与する複数のアカウントを用意するようにします。 アプリケーションからは、テーブル内のデータの読み取りと書き込みのアクセス権を付与するアクセス許可レベルのみを使用するようにします。 このような保護機能があれば、データベースのテーブルをドロップしたり、悪意のあるトリガーを導入したりすることを目的とした攻撃を排除できます。
クラウドネイティブ アプリケーションを構築する際には、ほとんどの部分で最小限の特権の原則を覚えておくと便利です。 ファイアウォール、ネットワーク セキュリティ グループ、ロール、ロールベースのアクセス制御 (RBAC) のスコープなどを設定する際にも役立ちます。
侵入テスト
アプリケーションが複雑になるにつれて、攻撃ベクトルの数は驚くべき速さで増加します。 脅威のモデル化は、システムの構築者と同一人物が行う傾向があるという欠点があります。 多くの開発者が、ユーザーとの対話を想定することに苦労し、使い勝手の悪いユーザー インターフェイスを作ってしまうのと同じように、ほとんどの開発者は、あらゆる攻撃ベクトルを把握することができません。 また、システムを構築している開発者が攻撃手法に精通しておらず、重要な何かを見逃している可能性もあります。
侵入テスト ("ペン テスト" とも呼ばれます) を行うには、外部のアクターを招き、システムへの攻撃を試みてもらいます。 こうした攻撃者は、外部のコンサルティング会社の場合や、優れたセキュリティ知識を持ち、別の業務を受け持つ他の開発者の場合があります。 その担当者には、システムの破壊を試みることができる自由裁量が与えられます。 多くの場合、パッチを適用する必要がある広範なセキュリティ ホールが見つけられます。 CEO に対してフィッシング攻撃を悪用するなど、まったく予期しないものが攻撃ベクトルとなることがあります。
Azure 自体も、Microsoft 内部のハッカー チームから常に攻撃を受けています。 長年にわたり、壊滅的な被害をもたらす可能性のある何十件もの攻撃ベクトルを彼らが最初に発見し、外部から悪用される前にそれらを閉じてきました。 ターゲットが魅力的であればあるほど、悪用しようとするアクターが絶えない可能性が高くなりますが、Azure よりも魅力的なターゲットは世界でも少数です。
監視
攻撃者がアプリケーションへの侵入を試みた場合、何らかの警告があるはずです。 多くの場合、サービスからのログを調べることで攻撃を発見できます。 攻撃には、その成功前に発見できる明らかな兆候があります。 たとえば、パスワードを推測しようとする攻撃者は、ログイン システムに対して多くの要求を行います。 ログイン システムの周辺を監視すると、通常のアクセス パターンとは異なる奇妙なパターンを検出することができます。 この監視をアラートにして、運用担当者に何らかの対策を講じるように警告することができます。 高度に成熟した監視システムの場合、要求をブロックしたり、応答を抑えたりする規則を事前に追加して、このような逸脱に基づいてアクションを実行することもできます。
ビルドをセキュリティで保護する
セキュリティが見落とされがちな場所の 1 つは、ビルド プロセスの周辺です。 ビルド時に、安全でないコードやチェックインの資格情報のスキャンなどのセキュリティ チェックを行うだけでなく、ビルド自体もセキュリティで保護する必要があります。 ビルド サーバーが侵害された場合、任意のコードを製品に取り込む絶好のベクトルとなります。
攻撃者が Web アプリケーションにサインインするユーザーのパスワードを盗もうとしているとします。 この場合、チェックアウトされたコードを修正し、任意のログイン要求を別のサーバーへミラーリングするビルド手順を組み込む可能性があります。 次にコードがビルドされると、自動的に更新されます。 ビルド前に実行されるため、ソース コードの脆弱性スキャンではこの脆弱性を検出できません。 同様に、ビルド手順はビルド サーバー上で実行されるため、コード レビューでは誰もこの脆弱性を発見できません。 悪用されたコードは運用環境に配置され、そこでパスワードが採取される可能性があります。 おそらく、ビルド プロセスの変更の監査ログがないか、少なくとも監査を監視している人は誰もいません。
このシナリオは、一見すると価値の低いターゲットを使用してシステムに侵入される可能性があるという完璧な例です。 攻撃者がシステムの境界を突破すると、任意の場所で実害を与えることができるレベルまでアクセス許可を昇格させる方法を見つける作業に取りかかれるようになります。
安全なコードの構築
.NET Framework は、既に非常に安全なフレームワークです。 配列の範囲から外れるなど、アンマネージド コードの落とし穴の一部を回避できます。 セキュリティ ホールが発見されると、それを修正する作業が積極的に行われます。 フレームワーク内の問題を見つけて、悪用するのではなく報告した研究者に対して対価を支払うバグ報奨金プログラムもあります。
.NET コードをより安全にする方法はたくさんあります。 .NET の「安全なコーディングのガイドライン」の記事のようなガイドラインに従うことは、最初から確実に安全なコードにするために合理的な手順です。 「OWASP Top Ten (OWASP トップ テン)」も安全なコードを構築するために貴重なガイドです。
ビルド プロセスは、運用環境に移行する前にソース コードの問題点を検出するスキャン ツールを配置するために適した場所です。 ほとんどのプロジェクトは、他のパッケージに依存しています。 古くなったパッケージをスキャンできるツールがあれば、ナイトリー ビルドでも問題を検出できます。 また、Docker イメージをビルドする場合でも、ベース イメージに既知の脆弱性がないことを確認しておくと便利です。 また、誰も誤って資格情報をチェックインしていないことも確認すべき点です。
組み込みのセキュリティ
Azure は、ほとんどのユーザーにとって使いやすさとセキュリティのバランスが取れるように設計されています。 ユーザーによってセキュリティ要件は異なるため、クラウド セキュリティへのアプローチを細かく調整する必要があります。 Microsoft は、トラスト センターで多くのセキュリティ情報を公開しています。 このリソースは、組み込まれている攻撃リスク軽減テクノロジのしくみを理解したいと考える担当者にとって、最初に参照すべき場所です。
Azure portal 内にある Azure Advisor は、環境を常にスキャンして推奨事項を提示するシステムです。 このような推奨事項には、ユーザーのコスト削減を目的としたものもあれば、仮想ネットワークによって保護されていないストレージ コンテナーが世界に向けて公開されているなど、潜在的に安全でない構成を特定するためのものもあります。
Azure ネットワーク インフラストラクチャ
オンプレミスのデプロイ環境では、ネットワークの設定に多大なエネルギーが費やされます。 ルーターやスイッチなどの設定は複雑な作業です。 ネットワークにより、特定のリソースと他のリソースとの通信が可能になりますが、場合によってはアクセスが阻止されます。 よくあるネットワーク規則として、開発途中のコードが暴走して大量のデータが削除されるという万が一の状況に備えて、開発環境から運用環境へのアクセスを制限するというものがあります。
既定では、ほとんどの PaaS Azure リソースには、最も基本的で許容度の高いネットワーク設定しかありません。 たとえば、インターネット上の誰でもアプリ サービスにアクセスできます。 新しい SQL Server インスタンスは、通常、外部からアクセスできないように制限されていますが、Azure 自体に使用される IP アドレスの範囲は許可されています。 つまり、SQL サーバーは外部の脅威から保護されていますが、攻撃者は Azure のブリッジ ヘッドを設定するだけで、そこから Azure 上のすべての SQL インスタンスに対して攻撃を仕掛けることができます。
幸いなことに、ほとんどの Azure リソースは、きめ細かなアクセス制御が可能な Azure 仮想ネットワークに配置することができます。 オンプレミス ネットワークを使用して広い世界から保護されたプライベート ネットワークを構築する方法と同様に、仮想ネットワークは、Azure ネットワーク内に配置されたプライベート IP アドレスの島です。
図 9-1 Azure 内の仮想ネットワーク
オンプレミス ネットワークに、ネットワークへのアクセスを管理するファイアウォールがあるように、仮想ネットワークの境界にも同様のファイアウォールを設置することができます。 既定では、仮想ネットワーク上のすべてのリソースは、インターネットとの通信が可能です。 何らかの形式の明示的なファイアウォール例外が必要なのは、受信接続のみです。
ネットワークを構築したら、ストレージ アカウントなどの内部リソースを、仮想ネットワーク上にあるリソースからのアクセスのみを許可するように設定することができます。 このファイアウォールにより、万が一、ストレージ アカウントのキーが漏えいしたとしても、攻撃者はそこに接続して漏えいしたキーを悪用することができないため、セキュリティ レベルが向上します。 このシナリオは、最小限の特権の原則の一例でもあります。
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 の 1 つ目のコンポーネントは、セキュリティ プリンシパルです。 セキュリティ プリンシパルは、ユーザー、グループ、サービス プリンシパル、またはマネージド 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 キューから読み取る例にスコープを適用すると、"Azure Service Bus エンドポイント blah.servicebus.windows.net/queue1 からメッセージを読み取る" という 1 つのキューにアクセス許可を絞り込むことができます。
スコープは、1 つのリソースのように狭くすることも、リソース グループ、サブスクリプション、または管理グループ全体に適用することもできます。
セキュリティ プリンシパルが特定のアクセス許可を持っているかどうかをテストする場合には、ロールとスコープの組み合わせが考慮されます。 この組み合わせにより、強力な承認メカニズムが実現します。
拒否
以前の RBAC には、"許可" 規則しか認められていませんでした。 この動作により、一部のスコープの構築が複雑になっていました。 たとえば、あるセキュリティ プリンシパルに 1 つを除くすべてのストレージ アカウントへのアクセスを許可するには、無限の可能性があるストレージ アカウントの一覧に明示的なアクセス許可を付与する必要がありました。 新しいストレージ アカウントを作成するたびに、このアカウント一覧に追加する必要がありました。 これにより、望ましくない管理のオーバーヘッドが増えることになりました。
拒否規則は許可規則よりも優先されます。 これで、同じ "1 つを除いてすべてを許可する" というスコープを、"すべてを許可する" と "この特定の 1 つを拒否する" という 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 Secrets は、一般的な 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
このようなシークレットは、ボリュームにマウントしたり、環境変数を介してコンテナー プロセスに公開したりすることができます。 Twelve-factor app (12 要素アプリ) というアプリケーション構築のアプローチでは、アプリケーションに設定を伝達する際に、最小公分母を使用することが推奨されています。 環境変数は、OS やアプリケーションに関係なくサポートされているため、最小公分母です。
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 のバージョンの中でも、接続の復号化を容易にするさまざまな設定があります。 最善の措置は、サーバーの接続に、最新の適切に構成されたプロトコルが使用されているかどうか確認することです。
この確認は、SSL ラボの SSL Server Test のような外部サービスで行うことができます。 一般的な Azure のエンドポイント (この場合はサービス バス エンドポイント) に対してテストを実行すると、ほぼ満点の A という結果が得られます。
Azure SQL データベースのようなサービスでも、データを隠すために TLS 暗号化が使用されています。 TLS を使用して転送中のデータを暗号化することの興味深い点は、Microsoft であっても、TLS を実行しているコンピューター間の接続をリッスンできないことです。 そのため、Microsoft 社員や、通常の攻撃者よりも多くのリソースを持つ国家機関のアクターによるリスクに、自社のデータがさらされているのではないかと懸念する企業も安心できます。
図 9-5 Service Bus エンドポイントのスコアを示す SSL ラボのレポート。
このレベルの暗号化は今後も常に十分であるとは言えませんが、Azure の TLS 接続は非常に安全であると確信できるはずです。 暗号化の向上に合わせて、Azure のセキュリティ標準を進化させ続ける予定です。 セキュリティ標準を監視し、その向上に合わせて誰かが Azure を更新するとわかっていることは便利です。
保存中
どのようなアプリケーションでも、データがディスク上に置かれる場所はいくつかあります。 アプリケーション コード自体は、何らかのストレージ メカニズムから読み込まれます。 また、ほとんどのアプリケーションには、SQL Server、Cosmos DB、さらには驚くほど低価格の Table Storage など、何らかのデータベースが使用されています。 このようなデータベースには、高度に暗号化されたストレージが使用され、適切なアクセス許可を持つアプリケーション以外はデータを読み取れないようになっています。 暗号化されたデータは、システム運用者でさえも読み取ることができません。 そのため、お客様は、シークレット情報の秘密が守られることに安心できます。
ストレージ
Azure の多くの部分を支えているのは、Azure Storage エンジンです。 仮想マシン ディスクは、Azure Storage 上にマウントされます。 Azure Kubernetes Service は、それ自体が Azure Storage 上でホストされている仮想マシン上で実行されます。 Azure Functions アプリや 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 に独自のキーを用意することができます。 このキー コンテナーには、キーのローテーションや失効などのサービスがあります。
TDS の "透過的" という部分は、暗号化されたデータベースを使用するためにクライアントを変更する必要がないという事実に由来しています。 このアプローチによって優れたセキュリティを実現できますが、データベースのパスワードが漏えいするだけで、ユーザーはデータを復号化できます。 データベース内の個々の列やテーブルを暗号化するアプローチもあります。 Always Encrypted を使用すると、データベース内の暗号化されたデータが平文で表示されることがないようにすることができます。
この暗号化レベルを設定するには、SQL Server Management Studio のウィザードを実行して、暗号化の種類と Key Vault のどこに関連するキーを格納するかを選択する必要があります。
図 9-6. Always Encrypted を使用して暗号化するテーブル内の列の選択。
このような暗号化された列から情報を読み取るクライアント アプリケーションの場合、暗号化されたデータを読み取るために特別な配慮をする必要があります。 接続文字列を Column Encryption Setting=Enabled を使用して更新し、クライアントの資格情報をキー コンテナーから取得する必要があります。 次に、SQL Server クライアントを列暗号化キーで準備する必要があります。 それが完了したら、残りのアクションには SQL クライアントへの標準的なインターフェイスを使用します。 つまり、Dapper や Entity Framework など、SQL クライアント上に構築されているツールを、変更せずにそのまま使用できます。 Always Encrypted は、まだすべての言語のすべての SQL Server ドライバーで使用できるわけではありません。
TDE と Always Encrypted の組み合わせは、どちらもクライアント固有のキーと共に使用できるため、最も厳格な暗号化要件でもサポートできます。
Cosmos DB
Cosmos DB は、Microsoft が Azure で提供する最新のデータベースです。 これは、セキュリティと暗号化を念頭に置いてゼロから構築されています。 AES-256bit 暗号化は、すべての Cosmos DB データベースの標準であり、無効にすることはできません。 通信の TLS 1.2 要件と組み合わされることで、ストレージ ソリューション全体が暗号化されます。
図 9-7. Cosmos DB 内のデータ暗号化のフロー。
Cosmos DB には、カスタマー暗号化キーを提供する機能がありませんが、それがなくても PCI-DSS に確実に準拠するように、チームは重要な作業に取り組んでいます。 また、Cosmos DB は、Azure SQL の Always Encrypted のような単一列の暗号化をサポートしていません。
セキュリティの維持
Azure には、高度なセキュリティで保護された製品をリリースするために必要なツールがすべてそろっています。 ただし、チェーンの強度は、その中で最も弱いリンクと同程度にしかなりません。 Azure 上にデプロイされたアプリケーションが、適切なセキュリティの考え方と適切なセキュリティ監査を使用して開発されていなければ、それはチェーンの中の弱いリンクになります。 Azure 上にインストールされたソフトウェアを、確実に Azure 自体と同じくらい安全にするには、多くの優れた静的解析ツール、暗号化ライブラリ、およびセキュリティ手法を使用できます。 例については、静的解析ツール、暗号化ライブラリ、セキュリティ手法のページを参照してください。
.NET