次の方法で共有

アプリケーション シークレットの保護に関する推奨事項

  • [アーティクル]

以下の Azure Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に対応します。

SE:09 ストレージを強化し、アクセスと操作を制限し、それらのアクションを監査することで、アプリケーション シークレットを保護します。 緊急時のローテーションに即興的に対応可能な、信頼性の高い定期的なローテーション プロセスを実行します。

このガイドでは、アプリケーション内の機密情報をセキュリティで保護するための推奨事項について説明します。 シークレットの適切な管理は、アプリケーション、ワークロード、および関連データのセキュリティと整合性を維持するために不可欠です。 シークレットを不適切に扱うと、データ侵害、サービスの中断、規制違反などの問題が発生する可能性があります。

API キー、Open Authorization (OAuth) トークン、Secure Shell (SSH) キーなどの資格情報はシークレットです。 クライアント側の OAuth トークンなどの一部の資格情報は実行時に動的に作成できます。 動的なシークレットは、その一時的な性質にもかかわらず、依然として保護する必要があります。 証明書やデジタル署名キーなどの非証明書情報も機密性が高い可能性があります。 コンプライアンス要件により、通常はシークレットと見なされない構成設定がアプリケーション シークレットとして扱われる場合があります。

定義 

期間 定義
証明書 暗号化または暗号化解除のための公開キーを保持するデジタル ファイル。
資格情報 通信チャネルの発行元またはコンシューマーの ID を確認するために使用される情報。
資格情報のスキャン シークレットが含まれていないことを確認するためにソース コードを検証するプロセス。
暗号化 データを読み取り不可能にし、シークレット コードでロックするプロセス。
キー 暗号化されたデータをロックまたはロック解除するために使用されるシークレット コード。
最小特権アクセス 職務を完了するための一連のアクセス許可を最小限にすることを目的としたゼロ トラスト原則。
マネージド ID リソースに割り当てられ、Azure によって管理される ID。
非シークレット 漏洩した場合でもワークロードのセキュリティ態勢を危険にさらさない情報。
回転 シークレットが侵害された場合でも限られた時間のみ使用可能となるように、シークレットを定期的に更新するプロセス。
Secret ワークロード コンポーネント間の通信を容易にするシステムの機密コンポーネント。 シークレットが漏洩すると、侵害につながる可能性があります。
X.509 公開キー証明書の形式を定義する標準。

重要

非シークレットをシークレットと同様に扱わないでください。 シークレットには、非シークレットには不要な運用上の厳密さが必要であり、その結果、余分なコストが発生する可能性があります。

アプリケーションが使用する API の URL などのアプリケーション構成設定は、非シークレットの例です。 この情報は、アプリケーション コードやアプリケーション シークレットと一緒に保存するべきではありません。 これらの設定を管理するには、Azure App Configuration などの専用の構成管理システムの使用を検討してください。 詳細については、「Azure App Configuration とは」を参照してください。

主要な設計戦略

シークレット管理戦略では、可能な限りシークレットを最小限に抑え、プラットフォーム機能を利用してシークレットを環境に統合する必要があります。 たとえば、アプリケーションにマネージド ID を使用する場合、アクセス情報は接続文字列に埋め込まれないため、情報を構成ファイルに保存しても安全です。 シークレットを保存および管理する前に、次の懸念事項を考慮してください。

  • 作成されたシークレットは、厳格なアクセス制御を備えた安全なストレージに保管する必要があります。

  • シークレットのローテーションはプロアクティブな操作ですが、失効はリアクティブです。

  • 信頼された ID のみがシークレットにアクセスできる必要があります。

  • シークレットへのアクセスを検査および検証するために、監査証跡を管理する必要があります。

これらの点を中心に戦略を構築して、なりすましを防ぎ、不必要な情報の露出を最小限に抑えます。

ワークロード シークレットを管理する

可能であれば、シークレットの作成は避けてください。 プラットフォームに責任委任する方法を見つけます。 たとえば、プラットフォームの組み込みマネージド ID を使用して資格情報を処理します。 シークレットの数が少ないほど、対象領域が減少し、シークレット管理にかかる時間が短縮されます。

キーには、ユーザー、管理者、および監査担当者の 3 つの異なるロールを持たせることをお勧めします。 ロールを区別することで、信頼された ID のみが適切なレベルのアクセス許可を持つシークレットにアクセスできるようになります。 開発者、管理者、およびその他の関連する担当者に、シークレット管理とセキュリティのベスト プラクティスの重要性について教育します。

事前共有キー

コンシューマーごとに個別のキーを作成することで、アクセスを制御できます。 たとえば、クライアントは事前共有キーを使用してサードパーティの API と通信します。 別のクライアントが同じ API にアクセスする必要がある場合は、別のキーを使用する必要があります。 2 つのコンシューマーが同じアクセス パターンまたはロールを持っている場合でも、キーを共有しないでください。 コンシューマーのスコープは時間の経過とともに変化する可能性があり、キーを共有した後はアクセス許可を個別に更新したり使用パターンを区別したりすることはできません。 個別のアクセス権を使用することで、失効も容易になります。 コンシューマーのキーが侵害された場合に、他のコンシューマーに影響を与えることなく、そのキーを失効したりローテーションしたりすることが容易になります。

このガイダンスは、さまざまな環境に適用されます。 同じキーを運用前環境と運用環境の両方で使用すべきではありません。 事前共有キーの作成を担当している場合は、複数のキーを作成して複数のクライアントをサポートするようにしてください。

詳細については、「ID およびアクセス管理に関する推奨事項」をご覧ください。

シークレットのストレージ

Azure Key Vault などのシークレット管理システムを使用して、セキュリティが強化された環境にシークレットを保存し、保存時と転送中は暗号化を行い、シークレットへのアクセスと変更を監査します。 アプリケーション シークレットを保存する必要がある場合は、簡単にローテーションできるようにソース コードの外部に保存します。

証明書は、Key Vault または OS の証明書ストアにのみ保存する必要があります。 たとえば、X.509 証明書を PFX ファイルまたはディスクに保存することはお勧めしません。 より高いレベルのセキュリティが必要な場合は、ソフトウェア ベースのシークレット ストアではなく、ハードウェア セキュリティ モジュール (HSM) 機能を備えたシステムを選択してください。

トレードオフ: HSM ソリューションは、より高いコストで提供されます。 セキュリティのレイヤーが追加されることで、アプリケーションのパフォーマンスに影響が出る可能性もあります。

専用のシークレット管理システムを使用すると、アプリケーション シークレットの保存、配布、アクセス制御が容易になります。 シークレット ストアにアクセスできるのは、承認された ID とサービスのみである必要があります。 システムへのアクセスは、アクセス許可を使用して制限できます。 アクセス許可を割り当てるときは、常に最小特権アプローチを適用します。

また、シークレット レベルでアクセスを制御する必要もあります。 各シークレットは、単一のリソース スコープにのみアクセスできる必要があります。 コンポーネントが必要なシークレットのみを使用できるように、分離境界を作成します。 分離されたコンポーネントが侵害されても、他のシークレットや、場合によってはワークロード全体を制御することはできません。 シークレットを分離する方法の 1 つは、複数のキー コンテナーを使用することです。 追加のキー コンテナーを作成しても追加コストはかかりません。

シークレット アクセスの監査と監視を実装します。 誰がいつシークレットにアクセスしたかをログに記録し、承認されていないアクティビティや疑わしいアクティビティを識別します。 セキュリティの観点からのログ記録の詳細については、「セキュリティの監視と脅威の検出に関する推奨事項」を参照してください。

シークレットのローテーション

シークレットの検疫を管理するプロセスを導入します。 シークレットの存続期間は、そのシークレットの管理に影響を与えます。 攻撃ベクトルを減らすには、シークレットをできるだけ頻繁に廃止して新しいシークレットに置き換える必要があります。

OAuth アクセス トークンは、有効期限を考慮して慎重に扱います。 露出期間より短い期間に調整する必要があるかどうかを検討します。 更新トークンは、アプリケーションへの露出を制限して安全に保存する必要があります。 証明書が更新された場合も、新しいキーを使用する必要があります。 更新トークンの詳細については、「OAuth 2.0 On-Behalf-Of 更新トークンをセキュリティで保護する」を参照してください。

シークレットは、有効期限が切れた場合、ワークロードで使用されなくなった場合、または侵害された場合は置き換えます。 逆に、緊急時以外はアクティブなシークレットを廃止しないでください。 アクセス ログを表示することで、シークレットの状態を確認できます。 シークレットのローテーション プロセスは、ワークロードの信頼性やパフォーマンスに影響を与えるべきではありません。 シークレット、コンシューマー、アクセス メソッドに冗長性を組み込む戦略を使用して、スムーズなローテーションを実現します。

Azure Storage によるローテーションの処理方法の詳細については、「アカウントのアクセス キーを管理する」を参照してください。

ローテーション プロセスは自動化し、人間の操作なしで配置されるようにする必要があります。 ローテーションの概念をネイティブにサポートするシークレット管理ストアにシークレットを保存すると、この運用タスクが簡略化されます。

ワークロード シークレットを安全に使用する

シークレット ジェネレーターまたはオペレーターは、シークレットを安全な方法で配布できる必要があります。 多くの組織では、ツールを使用して組織内および外部パートナーとシークレットを安全に共有します。 ツールがない場合は、承認を受けた受信者に資格情報を適切に引き渡すプロセスを用意します。 ディザスター リカバリー計画には、シークレットの復旧手順を含める必要があります。 キーが侵害されたり漏洩したりして、必要に応じて再生成する必要がある場合に備えたプロセスを用意します。 シークレットを使用するときは、安全性のために次のベスト プラクティスを検討してください。

ハードコーディングを禁止する

アプリケーション コード、構成ファイル、ビルド デプロイ パイプラインなどのコード成果物に、シークレットを静的テキストとしてハードコーディングしないでください。 このリスクの高い方法を使用すると、シークレットが読み取りアクセス権を持つすべてのユーザーに公開されるため、コードが脆弱になります。

マネージド ID を使用して資格情報を保存する必要性をなくすことで、この状況を回避できます。 アプリケーションでは、割り当てられた ID を使用して、ID プロバイダー (IdP) を介して他のリソースに対する認証を行います。 実際のシークレットが誤って露出するのを防ぐために、開発中に偽のシークレットを使用して非運用環境でテストします。

アプリケーション コードとビルド成果物に公開されているシークレットを定期的に検出するツールを使用します。 これらのツールは、ソース コードのコミットが展開される前に資格情報をスキャンする Git の事前コミット フックとして追加できます。 シークレットが誤って記録されないように、アプリケーション ログを定期的に確認してサニタイズします。 ピア レビューを通じて検出を強化することもできます。

Note

スキャン ツールでシークレットが検出された場合、そのシークレットは侵害されたと見なす必要があります。 失効するようにしてください。

シークレットのローテーションに対処する

ワークロード所有者は、ユーザーの中断を最小限に抑えながら新しいシークレットを組み込むことができるように、シークレットのローテーション計画とポリシーを理解する必要があります。シークレットがローテーションされると、古いシークレットが有効でなく、新しいシークレットが配置されていない期間が発生する可能性があります。 その期間中、アプリケーションがアクセスしようとしているコンポーネントは要求を承認しません。 コードに再試行ロジックを組み込むことで、これらの問題を最小限に抑えることができます。 また、同時アクセス パターンを使用すると、複数の資格情報を互いに影響を与えることなく安全に変更できるようになります。

運用チームと連携し、変更管理プロセスに参加します。 不要になった資格情報を使用するアプリケーションの一部を使用停止にする場合は、資格情報の所有者に通知する必要があります。

シークレットの取得と構成を自動配置パイプラインに統合します。 シークレットの取得により、配置中にシークレットが自動的にフェッチされるようにすることができます。 また、シークレット挿入パターンを使用して、実行時にアプリケーション コードまたは構成にシークレットを挿入することもできます。これにより、シークレットが誤ってログやバージョン管理に公開されるのを防ぐことができます。

Azure ファシリテーション

Key Vault を使用してシークレットを保存します。 シークレットは、Azure シークレット管理システム、Key Vault、Azure Managed HSM などの場所に保存します。 詳細については、「最適なキー管理ソリューションを選択する方法」を参照してください。

ID ベースのアクセス制御を統合します。 Microsoft Entra ID とマネージド ID は、シークレットの必要性を最小限に抑えるのに役立ちます。 Microsoft Entra ID は、キー ローテーションや異常などを処理するための組み込みメカニズムを使用して、アクセス制御のための非常に安全で使いやすいエクスペリエンスを提供します。

Azure ロールベースのアクセス制御 (RBAC) を使用して、特定のスコープ内のユーザー、グループ、アプリケーションにアクセス許可を割り当てます。

アクセス モデルを使用して、キー コンテナー、アクセス許可、シークレットを制御します。 詳細については、「アクセス モードの概要」を参照してください。

シークレットの露出検出を実装します。 疑わしいアクティビティを検出し、アプリケーション コード内の公開されたキーを定期的にチェックするプロセスをワークロードに統合します。 次に、いくつかの選択肢を示します。

アプリケーション構成ファイルまたは継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインには、どの環境の種類であってもキーとシークレットを保存しないでください。 開発者は、Visual Studio 接続済みサービスまたはローカルのみのファイルを使用して、資格情報にアクセスする必要があります。

セキュリティ チェックリスト

レコメンデーションの完全なセットを参照してください。

セキュリティ チェックリスト