アプリケーション シークレットを保護に関するレコメンデーション

  • [アーティクル]

この Power Platform Well-Architected Security チェックリストのレコメンデーションに適用されます。

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

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

API キー、Open Authorization (OAuth) トークン、Secure Shell (SSH) キーなどの資格情報はシークレットです。 コンプライアンス要件により、通常はシークレットとは見なされない構成設定がアプリケーション シークレットとして扱われる場合があります。

定義

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

重要

シークレットではないものを秘密のように扱わないでください。 シークレットには厳格な運用が必要ですが、非シークレットには不要であり、追加コストが発生する可能性があります。

アプリケーションに必要な API の URL など、シークレットではないアプリケーション設定は、アプリケーション コードやアプリケーション シークレットとは別に保持する必要があります。 アプリケーション構成を保存するには、カスタム コネクタまたは環境変数の使用を検討してください。 別のオプションは、Dataverse テーブルを使ってアプリケーション構成に関するメタデータを保存することです。 ただし、開発環境からテスト環境または本番環境に構成データを転送するなど、新しい環境でこのデータを入力する方法を見つける必要があります。 Dataflows を使って、これを行うことができます。

主要な設計戦略

シークレットを保存および管理する前に、次の考慮事項を考慮してください。

  • 作成されたシークレットは、厳格なアクセスの制御を備えた安全なストレージに保管する必要があります。
  • シークレットのローテーションはプロアクティブな操作ですが、失効は事後的な操作です。
  • 信頼できる ID のみがシークレットにアクセスできる必要があります。
  • シークレットへのアクセスを検査および検証するには、監査証跡を維持する必要があります。

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

シークレット管理の安全な実践

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

事前共有キー

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

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

詳細については、ID とアクセス管理のレコメンデーションを参照してください。

シークレット ストレージ

Azure Key Vault などの機密管理システムを利用して、シークレットを強化された環境に保存し、保存中および転送中の暗号化を行い、シークレットへのアクセスと変更を監査します。 アプリケーション シークレットを保存する必要がある場合は、ローテーションを容易にするためにソース コードの外に保管してください。

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

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

シークレット アクセスの監査と監視を実装します。 誰がいつシークレットにアクセスしたかを記録して、不正なアクティビティや疑わしいアクティビティを識別します。 セキュリティの観点からのログ記録については、監視と脅威の検出に関するレコメンデーション次を参照してください。

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

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

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

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

シークレットを使用するための安全な方法

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

ハードコーディングを防ぐ

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

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

注意

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

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

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

運用チームと協力して変更管理プロセスに参加します。 不要になった資格情報を使用するワークロードの一部を廃止するときは、資格情報の所有者に通知する必要があります。

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

Power Platform の促進

次のセクションでは、アプリケーション シークレットの管理に使用できる Power Platform 機能について説明します。

Azure Key Vault シークレットを使用する

環境変数を使用すると、Azure Key Vault に格納されているシークレットを参照できます。 これで、これらのシークレットを、Power Automate フローやカスタム コネクタで使用できます。 シークレットは、他のカスタマイズや一般に API 経由で使用することはできないことに注意してください。

実際のシークレットは Azure Key Vault にのみ保存され、環境変数は Key Vault のシークレット場所を参照します。 環境変数で Azure Key Vault シークレットを使用するには、Azure Key Vault を、Power Platform が参照したい特定のシークレットを読むことができるように構成する必要があります。 詳細については、ソリューションで環境変数を使用する および ソリューション カスタム コネクタで環境変数を使用するを参照してください。

ソリューション チェッカーを使用する

ソリューション チェッカー機能を使用すると、一連のベスト プラクティス ルールに対してソリューションで機能豊富なスタティック分析チェックを実行し、これらの問題となるパターンを識別できます。 チェックが完了すると、特定された問題、影響を受けるコンポーネントとコード、各問題を解決する方法が説明されたするドキュメントへのリンクが一覧になった詳細なレポートを受け取ります。 セキュリティ カテゴリで利用可能なソリューション チェッカー ルールを確認します。 詳細については、ソリューション チェッカーを使用して、ソリューションを検証するを参照してください。

CyberArk アクションを使用する

CyberArk は、人と機械の ID をエンドツーエンドで保護する ID セキュリティのプラットフォームを提供します。 Power Automate デスクトップ フローを使用すると、CyberArk から認証情報を取得できます。 詳細については、CyberArk アクション を参照してください。

参照

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

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

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