Azure Cosmos DB のデータベース セキュリティの概要

  • [アーティクル]

適用対象: NoSQL MongoDB Cassandra Gremlin Table

この記事では、データベースのセキュリティに関するベスト プラクティスと、データベース侵害を防止、検出、および対応するために役立つ Azure Cosmos DB の主な機能について説明します。

Azure Cosmos DB のセキュリティの新機能

保存時の暗号化が、すべての Azure リージョンの Azure Cosmos DB に保存されたドキュメントとバックアップに利用できるようになりました。 保存時の暗号化は、これらのリージョンの新規顧客と既存の顧客の両方に自動的に適用されます。 何も構成する必要はありません。 従来通り、保存時の暗号化によってデータが安全にセキュリティで保護されるメリットと同様にすばらしい待機時間、スループット、可用性、および機能を手に入れることができます。 Azure Cosmos DB アカウントに格納されたデータは、サービス マネージド キーを使用することで、Microsoft が管理するキーにより自動的かつシームレスに暗号化されます。 必要であれば、カスタマー マネージド キー (CMK) を使用することで、自分で管理するキーによる 2 つ目の暗号化レイヤーの追加を選択することができます。

データベースをセキュリティ保護する方法

データのセキュリティは、顧客自身とデータベース プロバイダーの共同責任です。 顧客として選択したデータベース プロバイダーによって、引き受ける責任の範囲は変化する可能性があります。 オンプレミス ソリューションを選択する場合、エンドポイントの保護からハードウェアの物理的なセキュリティに至るまでのすべてを自分で提供する必要がありますが、これは簡単な仕事ではありません。 Azure Cosmos DB などのサービスとしてのプラットフォーム (Paas) クラウド データベース プロバイダーを選択する場合、自分が関与する領域は大幅に減ります。 マイクロソフトの「Shared Responsibilities for Cloud Computing (クラウドコンピューティングの共同責任)」ホワイト ペーパーから借用した次の図は、Azure Cosmos DB のような PaaS プロバイダーを使用すると、顧客の責任がどのように減少するかを示しています。

Screenshot that shows customer and database provider responsibilities.

上の図は高度なクラウドのセキュリティ コンポーネントを示していますが、具体的には、どのような項目をデータベース ソリューションのために考慮する必要があるでしょうか。 どのようにすればソリューション同士を比較できますか?

次の要件のチェックリストを使用して、データベース システムを比較することをお勧めします。

  • ネットワークのセキュリティとファイアウォールの設定
  • ユーザー認証ときめ細かいユーザー制御
  • 局地的な障害に対応するためにデータをグローバルにレプリケートする能力
  • あるデータセンターから別のデータセンターにフェールオーバーする能力
  • データセンター内でのローカルなデータのレプリケーション
  • データの自動バックアップ
  • バックアップから削除されたデータの復元
  • 機密データの保護と分離
  • 攻撃の監視
  • 攻撃への対応
  • データ ガバナンス制約に対してデータをジオフェンスで準拠させる能力
  • 保護されたデータセンター内でのサーバーの物理的な保護
  • 認定資格

これは自明なことに思われるかもしれませんが、最近発生した大規模なデータベース侵害は、以下の単純ながらも重要な要件を思い出させてくれます。

  • 修正プログラムの適用によって常に最新の状態が維持されるサーバー
  • 既定/TLS 暗号化による HTTPS
  • 強力なパスワードを持つ管理者アカウント

Azure Cosmos DB がデータベースをセキュリティで保護する方法

上記の一覧を見直してみましょう。 これらのセキュリティ要件の内、Azure Cosmos DB が提供するものはいくつありますか? すべてです。

それぞれの詳細を確認しましょう。

セキュリティ要件 Azure Cosmos DB のセキュリティ手法
ネットワークのセキュリティ IP ファイアウォールの使用は、データベースをセキュリティ保護するための第 1 の保護層です。 Azure Cosmos DB は、受信ファイアウォールのサポートとして、ポリシーに基づく IP ベースのアクセス制御をサポートしています。 IP ベースのアクセス制御は、従来のデータベース システムで使用されているファイアウォール規則に似ています。 ただし、Azure Cosmos DB のデータベース アカウントは、承認されたマシンのセットまたはクラウド サービスからのみアクセスできるように拡張されています。 詳細については、「Azure Cosmos DB のファイアウォール サポート」を参照してください。

Azure Cosmos DB では、特定の IP アドレス (168.61.48.0)、IP 範囲 (168.61.48.0/8)、および IP と範囲の組み合わせを有効にできます。

Azure Cosmos DB は、この許可リスト外のマシンからやってくるすべての要求をブロックします。 承認されたコンピューターとクラウド サービスから送信された要求がリソースへのアクセス権を取得するには、認証プロセスを完了する必要があります。

仮想ネットワーク サービス タグを使用して、ネットワークの分離を実現し、一般のインターネットから Azure Cosmos DB リソースを保護できます。 セキュリティ規則を作成するときに、特定の IP アドレスの代わりにサービス タグを使用します。 規則の適切なソース フィールドまたは宛先フィールドでサービス タグ名 (例: AzureCosmosDB) を指定することで、対応するサービスのトラフィックを許可または拒否できます。
承認 Azure Cosmos DB は、承認のためにハッシュ ベースのメッセージ認証コード (HMAC) を使用します。

各要求は、シークレット アカウント キーを使用してハッシュされ、その後の base 64 エンコード ハッシュは Azure Cosmos DB の呼び出しと一緒に送信されます。 Azure Cosmos DB は、要求を検証するために、適切なシークレット キーとプロパティを使用してハッシュを生成した後、その値と要求に含まれる値を比較します。 2 つの値が一致した場合、操作の承認が成功し、要求が処理されます。 一致しない場合、承認は失敗し、要求は拒否されます。

プライマリ キーまたはリソース トークンのどちらかを使用して、ドキュメントなどのリソースに対するきめ細かいアクセスを実現できます。

詳細については、「Azure Cosmos DB リソースへのアクセスのセキュリティ保護」を参照してください。
ユーザーおよびアクセス許可 アカウントのプライマリ キーを使用することで、ユーザー リソースとアクセス許可リソースをデータベースごとに作成できます。 リソース トークンは、データベース内のアクセス許可に関連付けられ、ユーザーがデータベース内のアプリケーション リソースにどのようにアクセスできるか (読み取り/書き込み、読み取り専用、またはアクセスなし) を判断します。 アプリケーション リソースには、コンテナー、ドキュメント、添付ファイル、ストアド プロシージャ、トリガー、UDF が含まれます。 リソース トークンは認証中に使用され、リソースへのアクセスが提供されるか拒否されます。

詳細については、「Azure Cosmos DB リソースへのアクセスのセキュリティ保護」を参照してください。
Active Directory 統合 (Azure ロールベースのアクセス制御) Azure portal でアクセスの制御 (IAM) を使用することで、Azure Cosmos DB アカウント、データベース、コンテナー、およびオファー (スループット) へのアクセスを提供または制限することもできます。 IAM は ロールベースのアクセス制御を提供し、Active Directory と統合されています。 組み込みのロールまたはカスタム ロールは、個人とグループに使用できます。 詳細については、「Active Directory 統合」を参照してください。
グローバル レプリケーション Azure Cosmos DB は、ターンキー方式で世界中にある Azure のデータセンターのいずれかにデータをレプリケートできるようにするターンキー グローバル分散を提供しています。 グローバル レプリケーションでは、グローバルなスケールを行い、全世界のデータに低待機時間でアクセスすることができます。

セキュリティの点では、グローバル レプリケーションは、局地的な障害からデータが保護されることを保証します。

詳細については、「データのグローバル分散」を参照してください。
リージョン間フェールオーバー 複数のデータセンターへのデータのレプリケーションが完了している場合、あるリージョンのデータセンターがオフラインになった場合、Azure Cosmos DB は自動的に操作をロールオーバーします。 データをレプリケートするリージョンを使用して、フェールオーバー リージョンの優先度リストを作成できます。

詳細については、「Azure Cosmos DB のリージョン内フェールオーバー」を参照してください。
ローカル レプリケーション Azure Cosmos DB は、単一のデータセンター内でも、高可用性のためにデータを自動的にレプリケートし、整合性レベルは自分で選択できます。 このレプリケーションによって、すべての単一リージョン アカウントと緩やかな整合性を持つすべての複数リージョン アカウントに対する 99.99% の可用性 SLA、およびすべての複数リージョン データベース アカウントに対する 99.999% の読み取り可用性が保証されます。
オンライン バックアップの自動化 Azure Cosmos DB データベースは定期的にバックアップされ、geo 冗長ストアに保存されます。

詳細については、「Azure Cosmos DB での自動オンライン バックアップと復元」を参照してください。
削除されたデータの復元 誤ってデータを削除した場合、30 日以内であれば自動オンライン バックアップを使用してデータを復元することができます。

詳細については、「Azure Cosmos DB での自動オンライン バックアップと復元」を参照してください
機密データの保護と分離 「新機能」に示されているリージョンのすべてのデータが保存時に暗号化されます。

個人データと他の機密データをそれぞれ特定のコンテナーへと分離して、読み取り/書き込みまたは読み取り専用アクセスを特定のユーザーに限定することができます。
攻撃の監視 監査ログとアクティビティ ログを使用すると、アカウントの正常なアクティビティと異常なアクティビティを監視できます。 リソースに対して実行された操作を表示できます。 このデータには、操作を開始した人物、操作が発生したタイミング、操作の状態などが含まれます。
攻撃への対応 Azure サポートに連絡して攻撃の可能性を報告すると、5 段階のインシデント対応プロセスが開始されます。 目標は、通常サービスのセキュリティと運用を復元することです。 このプロセスは、問題が検出され調査が開始された後、可能な限り早急にサービスを復元します。

詳細については、「Microsoft Azure のクラウドのセキュリティ対応」を参照してください。
ジオフェンス Azure Cosmos DB は、ソブリン リージョン (ドイツ、中国、米国政府など) のデータ ガバナンスを保証します。
施設の保護 Azure Cosmos DB 内のデータは、Azure の保護されたデータセンター内のソリッド ステート ドライブに保存されます。

詳細については、「Microsoft グローバル データセンター」を参照してください。
HTTPS/SSL/TLS の暗号化 Azure Cosmos DB へのすべての接続で HTTPS がサポートされます。 Azure Cosmos DB では、1.2 (これを含む) までの TLS レベルがサポートされます。
サーバー側で最低限の TLS レベルを強制することが可能です。 これを行うには、セルフサービス ガイドの「Azure Cosmos DB における最小 TLS バージョンの強制のセルフサービス」を参照してください。
保存時の暗号化 Azure Cosmos DB 内のすべての格納データは、保存時に暗号化されます。 「Azure Cosmos DB の保存時の暗号化」で詳細を確認してください。
サーバーへの修正プログラムの適用 マネージド データベースである Azure Cosmos DB では、サーバーの管理とパッチ適用が自動的に行われるので、それらを行う必要がありません。
強力なパスワードを持つ管理者アカウント Azure Cosmos DB にパスワードのない管理アカウントを作成することは不可能です。

TLS と HMAC シークレットベース認証を介したセキュリティは、既定で組み込まれています。
セキュリティとデータ保護の認証 認定資格の最新リストについては、Azure Cosmos DB を含むすべての Azure 認定資格が記載された「Azure コンプライアンス」と「Azure コンプライアンス ドキュメント」を参照してください。

次のスクリーンショットは、監査ログとアクティビティ ログを使用して自分のアカウントを監視する方法を示しています。 Screenshot that shows activity logs for Azure Cosmos DB.

主/セカンダリ キー

主/セカンダリ キーにより、データベース アカウントのすべての管理リソースへのアクセスが提供されます。 主/セカンダリ キー:

  • アカウント、データベース、ユーザー、およびアクセス許可へのアクセスを提供します。
  • コンテナーとドキュメントへのきめ細かいアクセスを提供するために使用することはできません。
  • アカウントの作成時に作成されます。
  • いつでも再生成することができます。

各アカウントは、プライマリ キーとセカンダリ キーという 2 つのキーで構成されます。 デュアル キーの目的は、アカウントとデータに継続的にアクセスできるようにしながら、キーの再生成またはロールを行えるようにすることです。

主/セカンダリ キーには、読み取り/書き込みと読み取り専用の 2 つのバージョンがあります。 読み取り専用キーは、アカウント上の読み取り操作のみを許可します。 これらは、アクセス許可リソースを読み取るためのアクセス権は提供しません。

キーのローテーションと再生成

キーのローテーションと再生成のプロセスは単純です。 まず、Azure Cosmos DB アカウントにアクセスするために、アプリケーションで主キーまたはセカンダリ キーのいずれかを一貫して使用していることを確認します。 その後、次のセクションの手順に従ってください。 キーの更新とキーの再生成についてアカウントを監視するには、「メトリックとアラートを使用したキーの更新の監視」を参照してください。

アプリケーションで現在主キーを使用中の場合

  1. Azure portal で Azure Cosmos DB アカウントに移動します。

  2. 左側のメニューから [キー] を選択した後、セカンダリ キーの右側にある省略記号 (...) から [セカンダリ キーの再生成] を選択します。

    Screenshot showing how to regenerate the secondary key in the Azure portal when used with the NoSQL API.

  3. 新しいセカンダリ キーが Azure Cosmos DB アカウントに対して一貫して機能していることを確認します。 Azure Cosmos DB アカウントのサイズに応じて、キーの再生成にかかる時間は 1 分から数時間までさまざまです。

  4. アプリケーションで、主キーをセカンダリ キーに置き換えます。

  5. Azure portal に戻り、主キーの再生成をトリガーします。

    Screenshot showing how to regenerate the primary key in the Azure portal when used with the NoSQL API.

アプリケーションでセカンダリ キーが現在使用されている場合

  1. Azure portal で Azure Cosmos DB アカウントに移動します。

  2. 左側のメニューから [キー] を選択した後、プライマリ キーの右側にある省略記号 (...) から [プライマリ キーの再生成] を選択します。

    Screenshot that shows how to regenerate the primary key in the Azure portal when used with the NoSQL API.

  3. 新しい主キーが Azure Cosmos DB アカウントに対して一貫して機能していることを確認します。 Azure Cosmos DB アカウントのサイズに応じて、キーの再生成にかかる時間は 1 分から数時間までさまざまです。

  4. アプリケーションで、セカンダリ キーを主キーに置き換えます。

  5. Azure portal に戻り、セカンダリ キーの再生成をトリガーします。

    Screenshot that shows how to regenerate the secondary key in the Azure portal when used with the NoSQL API.

キーの再生成の状態を追跡する

キーをローテーションまたは再生成したら、アクティビティ ログからその状態を追跡できます。 状態を追跡するには、以下の手順を使用します。

  1. Azure portal にサインインし、Azure Cosmos DB アカウントに移動します。

  2. 左側のメニューから [キー] を選択します。 各キーの下に、最後のキーの再生成日が表示されます。

    Screenshot that shows status of key regeneration from the activity log.

    少なくとも 60 日に 1 回はキーを再生成することをお勧めします。 最後の再生成が 60 日より前である場合は、警告アイコンが表示されます。 また、キーが記録されていないことも確認できました。 この場合、アカウントは 2022 年 6 月 18 日より前に作成され、日付は登録されなかったことになります。 ただし、新しいキーを再生成して、その新しい最終再生成日を確認できる必要があります。

  3. キーの再生成イベントと、その状態、操作が実行されたタイミング、キーの再生成を開始したユーザーの詳細が表示されるはずです。 キー生成操作は、承認済み状態で開始します。 状態は、開始に変化した後、操作が完了したときに成功に変化します。

次のステップ