次の方法で共有

シークレットを保護するためのベスト プラクティス

  • [アーティクル]

この記事では、シークレットを保護し、不正アクセスのリスクを軽減するためのガイダンスを提供します。 資格情報などの機密情報を、コード、GitHub リポジトリ、ログ、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインなどに格納しないようにするには、このガイダンスに従います。 この記事のガイダンスは、個々のサービスの推奨事項と、Microsoft クラウド セキュリティ ベンチマーク (MCSB) からまとめられたものです。

全般的なベスト プラクティス

今日のデジタル環境では、アプリケーションの資格情報や機密情報などの機密情報をセキュリティで保護することが最も重要です。 侵害は、データの損失、金銭的ペナルティ、評判の低下などの深刻な結果につながる可能性があります。 これらのリスクを軽減するには、包括的なシークレット管理戦略の実装が不可欠です。

監査を実施してシークレットを特定する

シークレットをセキュリティで保護する前に、シークレットがどこにあるのかを知る必要があります。 システムとアプリケーションの徹底的な監査を実施すると、保護が必要なすべての機密情報を特定するのに役立ちます。 これには、パスワード、API キー、接続文字列、その他の資格情報が含まれます。 定期的な監査により、新しいシークレットが把握され、既存のものが適切に管理されていることを確認できます。

一時的である可能性がある OAuth トークンなどの動的に作成されたシークレットであっても、長期的なシークレットと同じ厳密さで保護する必要があることに注意することが重要です。

シークレットのハードコーディングを避ける

シークレットをコードまたは構成ファイルに直接埋め込むのは、重大なセキュリティ リスクになります。 コードベースが侵害されると、シークレットも侵害されます。 代わりに、環境変数または構成管理ツールを使用してソース コードに機密情報が含まれないようにしてください。 これにより、不注意による露出のリスクが最小限に抑えられ、シークレットの更新プロセスが簡略化されます。

さらに、シークレットの取得を自動化されたデプロイ パイプラインに統合し、シークレット挿入パターンを使用すると、ログやバージョン コントロールでシークレットが誤って公開されるのを防ぎ、デプロイ プロセスのセキュリティをさらに強化できます。

「アプリケーション シークレットを保護するための推奨事項」を参照してください

セキュリティで保護されたキー ストアを使用する

セキュリティで保護されたキー ストアを利用すると、シークレットが安全で暗号化された場所に格納されます。 Azure Key Vault や Azure マネージド HSM などのサービスは、アクセス制御、ログ、自動ローテーションなどの堅牢なセキュリティ機能を提供します。 このアプローチにより、シークレットの管理が一元化され、不正アクセスのリスクが軽減されます。

セキュリティをさらに強化するには、特に機密性の高いシークレットや重要なシークレットの場合、ハードウェア セキュリティ モデル (HSM) のキー ストアを使用してシークレットを暗号化することを検討してください。これにより、ソフトウェアベースのシークレット ストアと比較して保護が強化されます。 Azure のすべてのキー管理サービスの概要と、選択に関するガイダンスについては、「Azure でのキー管理」と「適切なキー管理ソリューションを選択する方法」を参照してください。

シークレット スキャン ツールを実装する

コードベースで埋め込まれたシークレットを定期的にスキャンすると、不注意による露出を防ぐことができます。 Azure DevOps Credential Scanner や GitHub シークレット スキャン機能などのツールを使用すると、リポジトリ内にあるシークレットを自動的に検出して警告することができます。 これらのツールを CI/CD パイプラインに統合することで、継続的な監視が保証されます。 これらのスキャン ツールによって検出されたシークレットはセキュリティ侵害として扱うことが重要です。つまり、セキュリティ態勢の整合性を維持するには、直ちに取り消して置き換える必要があります。

マネージド ID を利用する

Azure のマネージド ID は、アプリケーションがコードに資格情報を保存することなく、Azure サービスに対して認証を行うための安全な方法を提供します。 Azure リソース用マネージド ID を有効にすることで、Azure Key Vault やその他のサービスに安全な方法でアクセスでき、シークレットを手動で処理する必要が減ります。 このアプローチでは、シークレットの作成が最小限に抑えられるだけでなく、資格情報の管理責任がプラットフォームに委任されるため、潜在的な侵害の対象となる領域も削減されます。

詳細なアクセス制御を適用する

シークレットに対して詳細なアクセス制御を適用することで、最小限の特権の原則に従います。 Azure ロールベースのアクセス制御 (RBAC) を使用して、許可されたエンティティのみが特定のシークレットにアクセスできるようにします。 定期的にアクセス許可を確認して更新し、不正アクセスを防ぎます。 また、ユーザー、管理者、監査人などの個別のロールを実装してシークレットへのアクセスを管理し、信頼できる ID のみが適切なレベルのアクセス許可を持つようにすることもお勧めします。

Azure Key Vault RBAC のガイドを参照してください。

シークレットを定期的にローテーションする

シークレットは時間の経過と共に漏洩や露出の影響を受けやすくなります。 シークレットを定期的にローテーションすると、不正アクセスのリスクが軽減されます。 特定のシークレットについては、Azure Key Vault でシークレットをローテーションできます。自動的にローテーションできない場合は、手動ローテーション プロセスを確立し、使用されなくなったときに確実に削除されるようにします。

シークレットのローテーション プロセスを自動化し、シークレット管理に冗長性を組み込むことで、ローテーションによってサービスの可用性が中断されないようにすることができます。 再試行ロジックと同時アクセス パターンをコードに実装すると、ローテーション期間中の問題を最小限に抑えるのに役立ちます。

アクセスの監視とログ

シークレット管理システムのログと監視を有効にして、アクセスと使用状況を追跡します。 Key Vault のログおよび/または、Azure Monitor や Azure Event Grid などのサービスを使用して、シークレットに関連するすべてのアクティビティを監視します。 これにより、シークレットにアクセスしたユーザーを可視化し、疑わしい動作や潜在的なセキュリティ インシデントを検出するのに役立ちます。 詳細な監査証跡を維持することは、シークレットへのアクセスを検査および検証するために重要です。これは、なりすましを防ぎ、否認を回避し、不要な露出を減らすのに役立ちます。

ネットワークの分離を実装する

ネットワークの分離を実装することで、シークレットの露出を減らします。 ファイアウォールとネットワーク セキュリティ グループを構成して、キー コンテナーへのアクセスを制限します。 信頼できるアプリケーションとサービスのみにシークレットへのアクセスを許可し、攻撃面を最小限に抑え、不正アクセスを防ぎます。 さらに、複数のキー コンテナーを使用してさまざまなコンポーネントの分離境界を作成し、1 つのコンポーネントが侵害された場合に他のシークレットやワークロード全体を制御できないようにすることを検討してください。

保存中および転送中のシークレットを暗号化する

シークレットが保存時と転送時の両方で暗号化されていることを確認します。 Azure Key Vault は、エンベロープ暗号化を使用してシークレットを安全な方法で格納します。データ暗号化キー (DEK) はキー暗号化キー (KEK) によって暗号化され、さらなるセキュリティ レイヤーが提供されます。 このアプローチにより、不正アクセスに対する保護が強化されます。 さらに、HTTPS などの安全な通信プロトコルを使用して、アプリケーションとキー コンテナーの間で転送されるデータを暗号化し、保存中と転送中の両方でシークレットが確実にセキュリティで保護されるようにします。

Azure では、保存時の暗号化は AES 256 暗号化を使用してさまざまなサービスに実装されますが、転送中のデータは TLS および MACsec によってセキュリティで保護され、転送中の不正アクセスを防ぎます。 これらの暗号化手法により、データが格納されているか、システム間で転送されているかに関係なく、データが包括的に保護されます。 詳細については、保存時および転送時の暗号化に関するページを参照してください。

シークレットの安全な配布

シークレットを配布するときは、組織内外で安全な方法で共有されるようにします。 安全に共有できるように設計されたツールを使用し、ディザスター リカバリー計画にシークレットの回復手順を組み込みます。 キーが侵害された、または漏洩した場合は、直ちに再生成する必要があります。 セキュリティをさらに強化するには、たとえ同様のアクセス パターンがある場合でも、キーを共有するのではなく、コンシューマーごとに個別のキーを使用します。 これにより、キーの管理と失効が簡略化され、侵害されたキーを他のコンシューマーに影響を与えることなく取り消すことができます。

サービス固有のベスト プラクティス

個々のサービスには、シークレットを保護するための追加のベスト プラクティスとガイダンスがある場合があります。 次に例をいくつか示します。

次のステップ

セキュリティ リスクを最小限に抑えることは、共同責任です。 ワークロードをセキュリティで保護するための手順を率先して行う必要があります。 クラウドでの共同責任について詳細を学びます。

Azure を使用してクラウド ソリューションを設計、デプロイ、管理するときに使用するセキュリティのベスト プラクティスの詳細については、「Azure セキュリティのベスト プラクティスとパターン」を参照してください。