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

  • [アーティクル]

この Azure Well-Architected Framework セキュリティ チェックリストの推奨事項に適用されます。

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

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

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

定義 

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

重要

シークレットのように非シークレットを扱ってはいけません。 シークレットには、非シークレットでは不要であり、追加コストが発生する可能性がある運用上の厳しさが必要です。

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

主要な設計戦略

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

  • 作成されたシークレットは、厳密なアクセス制御を使用してセキュリティで保護されたストレージに保持する必要があります。

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

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

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

これらのポイントに関する戦略を立て、ID の盗難を防ぎ、否認を回避し、情報への不必要な露出を最小限に抑えます。

シークレット管理の安全なプラクティス

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

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

事前共有キー

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

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

詳細については、「 ID とアクセス管理の推奨事項」を参照してください。

シークレット ストレージ

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

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

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

専用のシークレット管理システムを使用すると、アプリケーション シークレットへのアクセスを簡単に格納、配布、および制御できます。 シークレット ストアにアクセスできるのは、承認された ID とサービスのみです。 システムへのアクセスは、アクセス許可を使用して制限できます。 アクセス許可を割り当てるときは、常に最小特権のアプローチを適用します。

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

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

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

シークレットの検疫を維持するプロセスを用意します。 シークレットの寿命は、そのシークレットの管理に影響します。 攻撃ベクトルを減らすには、シークレットを廃止し、できるだけ頻繁に新しいシークレットに置き換える必要があります。

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

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

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

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

シークレットを使用するための安全なプラクティス

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

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

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

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

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

注意

スキャン ツールでシークレットが検出された場合、そのシークレットは侵害されたと見なす必要があります。 取り消す必要があります。

シークレットローテーションに応答する

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

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

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

Azure ファシリテーション

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

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

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

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

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

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

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

推奨事項の完全なセットを参照してください。

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