Azure 環境のセキュリティ保護
環境を制御し、デプロイ パイプラインをセキュリティで保護する方法を理解したので、制御された環境への人間のアクセスを無効にすることを検討できます。 このユニットでは、Azure 環境に対してユーザーのアクセス許可を構成する方法について学習します。 緊急事態にアクセスを許可する方法、Azure 資産で発生した変更を監査する方法も含みます。
人間のアクセスをブロックする
制御された環境への人間のアクセスをブロックすることで、偶発的または悪意のある変更がチームのレビューと自動化されたデプロイ プロセスを迂回できないようにします。 人間のアクセスをブロックしない場合、リポジトリとパイプラインの全体で計画と実装に多くの時間を費やした制御を、誰かが誤って回避する可能性があります。
ブロック制御がなければ、誰かが誤って何かを壊すことも簡単です。 たとえば、ユーザーが開いている Azure portal のコピーが 2 つあるとします。 1 つはテスト環境用で、もう 1 つは運用環境用です。 ユーザーがブラウザーのタブを切り替えたり戻ったりしているうちに、テスト環境に加えるはずの変更を誤って運用環境に加えることは容易です。
人間のアクセスをブロックするには、Azure ロールベースのアクセス制御 (RBAC) を使用します。 RBAC では、以下を定義する "ロールの割り当て" を作成します。
- 定義された一連の Azure リソース (スコープ) にアクセスできるユーザー、グループ、またはサービス プリンシパル。
- それらのユーザー、グループ、またはサービス プリンシパルがリソース ("ロール") にアクセスするときに実行できること。
Azure RBAC には、次のような組み込みのロールの種類が多数用意されています。
- "閲覧者" は、環境に対して読み取り専用アクセスができます。
- "共同作成者" はリソースを変更できます。
- "所有者" は、リソースを変更すること、他のユーザーにアクセスを許可できます。
適切なスコープのアクセスを許可することが重要です。 組織が推奨される方法に従って、環境ごとに専用の Azure サブスクリプションを使用する場合は、Azure 管理グループを使用してロールの割り当てのスコープを簡略化することを検討してください。 組織がすべての環境に対して 1 つの Azure サブスクリプションを使用している場合は、制御された環境を含むすべてのリソースによってそのアクセス許可が継承されるため、人間にサブスクリプション全体へのアクセス権を付与することは避けてください。
ヒント
ロールの割り当ては、Azure Resource Manager (ARM) リソースです。 つまり、Bicep を使用するなどして、コードで Azure RBAC ロールの割り当てを構成できます。
ロールの割り当てを計画するときは、ご自身の組織にとって何が理にかなっているかを判断する必要があります。 たとえば、組織で環境ごとに個別のサブスクリプションを作成するとします。 管理者と開発者に対して、制御された環境への "閲覧者" アクセスを許可することを選択できます。 このロールを使用すると、Azure portal 内の運用環境にアクセスして、リソースの構成を確認し、メトリックとログを表示し、環境に変更を加えずに問題やバグを調査できます。
Azure 管理者と、コードやスクリプトを記述する開発者の両方について、玩具会社の環境にロールの割り当てを構成する方法を次に示します。
| 環境名 | コントロールのレベル | 管理者のアクセス許可 | 開発者のアクセス許可 |
|---|---|---|---|
| 開発 | 制御 | Reader | Reader |
| テスト | 制御 | Reader | Reader |
| ステージング | 制御 | Reader | Reader |
| Production | 制御 | Reader | Reader |
| デモ | 制御されない | 所有者 | Contributor |
| パフォーマンス テスト | 制御されない | 所有者 | なし |
| 侵入テスト | 制御されない | 所有者 | なし |
| PR レビュー | 制御されない | 所有者 | 所有者 |
| 開発サンドボックス | 制御されない | 所有者 | 所有者 |
ロールの割り当てを計画するときは、必ず十分にテストしてください。 場合によっては、管理操作に必要なアクセス許可が明白ではないことがあります。 チーム メンバーに、使用する予定のアクセス許可を使って、日々のすべての作業をテストする機会を与えてください。 発生した問題があれば確認します。
ロールの割り当てを定期的に監査します。 誤って間違ったユーザーへのアクセスを許可したり、広範囲すぎるアクセスを許可したりしていないことを確認します。
データ プレーン アクセス
Azure には 2 種類の操作があります。
- "コントロール プレーン操作" は、サブスクリプション内のリソースを管理します。
- "データ プレーン操作" は、リソースによって公開されている機能にアクセスします。
たとえば、コントロール プレーン操作を使用してストレージ アカウントを作成します。 データ プレーン操作を使用してストレージ アカウントに接続し、それに含まれるデータにアクセスします。
Azure リソースへの直接ユーザー アクセスをブロックする場合は、この制限がデータ プレーン操作にどのように適用されるかも考慮してください。 たとえば、デプロイ プロセスで、管理者がアクセスできる場所にストレージ アカウントのキーを格納できます。 その管理者が、管理を回避してストレージ アカウントのデータ プレーンに直接アクセスするためのキーを使用できる場合もあります。
Microsoft Entra ID を使ったデータ プレーンアクセス制御の構成をサポートする Azure リソースが増えています。 このサポートにより、キーが漏洩したり、データ プレーンへのアクセスを誤って許可したりする可能性が低くなります。 データ プレーンへのアクセスには、できる限り Microsoft Entra ID を使うことをお勧めします。
緊急アクセス
場合によっては、緊急事態が発生し、誰かが運用環境にすばやくアクセスして問題を調査または解決する必要があります。 このような緊急事態が発生する前に、どのように対応するかを計画し、リハーサルすることが重要です。 障害の最中に対応のために招集をかける必要はありません。
考慮すべきアプローチの 1 つは、"非常用アカウント" です。これは、ユーザーに通常許可されるよりも高いレベルのアクセスを許可された、特別なユーザー アカウントです。 "非常用" アカウントと呼ばれるのは、火災警報パネルのガラスを割るのと同じように、資格情報にアクセスするために通常とは異なる何らかの対応が必要とされるためです。 非常用アカウントの資格情報にオペレーターがアクセスするための安全な方法を用意しておくことができます。 そうすれば、オペレーターは、緊急時の変更を実行するアカウントとしてサインインできます。
非常用アカウントを使用するための一連の手順は次のとおりです。
- ユーザーは通常のアカウントを使用して緊急時の変更を実行しようとしますが、通常のユーザー アカウントには十分なアクセス許可がないため、操作はブロックされます。
- ユーザーは、非常用アカウントの資格情報にアクセスし、そのユーザーとしてサインインします。
- ユーザー (非常用アカウントとして機能する) は、操作の実行を許可されます。
非常用アカウントを使用するには、高度な規範が必要です。 その使用は、実際の緊急事態のために予約されている必要があります。 アカウントには高度な特権があるため、資格情報を慎重に管理して保護します。 非常用アカウントの資格情報は、漏えいしたり侵害されたりする可能性を最小限に抑えるために、頻繁に変更することをお勧めします。
非常用アカウントはチーム内で共有されることが多いため、誰がアカウントを使用したか、そのユーザーが何をしたかを追跡するのは困難です。 緊急用アカウントに関する別の方法に、Microsoft Entra Privileged Identity Management (PIM) 機能を採用することがあります。 これにより、ユーザー自身のアカウントに、より高いレベルのアクセスを一時的に許可できます。
PIM を使用する一連の手順は次のとおりです。
ユーザーは通常のアカウントを使用して緊急時の変更を実行しようとしますが、通常のユーザー アカウントには十分なアクセス許可がないため、操作はブロックされます。
ユーザーは PIM に連絡し、アクセス許可の一時的な昇格を要求します。
PIM は、組織でどのように構成されているかに応じて、ユーザーの ID の追加検証を実行したり、誰かに承認を求めたりすることがあります。
要求が承認された場合、PIM はユーザーのアクセス許可を一時的に更新します。
ユーザーに操作の実行が許可されます。
定義された期間が経過すると、PIM はユーザーに許可した昇格済みのアクセス許可を取り消します。
PIM と Azure の両方で、昇格済みのアクセス許可を要求したユーザーとその理由を理解するのに役立つ包括的な監査ログが書き込まれます。 ログでは、アクセス許可が付与されたときに環境内で実行された内容も追跡されます。
Note
PIM には、Microsoft Entra ID の Premium ライセンスが必要です。
緊急事態が終わった後
緊急事態が終わった後に通常の運用に戻るプロセスを用意しておくことが重要です。 長い時間が経過する前にこのプロセスに従ってください。そうしないと、重要な情報を忘れたり、構成が安全でない状態のままになるリスクがあります。
Azure と PIM の監査ログを注意深く確認して、制御された環境、特に運用環境で実行された変更を把握します。
重要
PIM または非常用アカウントを使用するユーザーは、自分の通常のユーザー アカウントに、本来必要な範囲を超えたアクセスを許可する機会を得る可能性があります。 また、アクセス許可が取り消された後も引き続き使用できるデータ プレーン キーへのアクセス権を取得するために、一時的なアクセス許可を使用する場合もあります。
非常用アカウントまたは PIM のすべての使用を綿密に監査します。 緊急時に公開された可能性のあるキーを取り消すか、ローテーションします。
緊急事態の直後に、コードとしてのインフラストラクチャ資産を、緊急時に行われた変更と "再同期" します。 たとえば、緊急の問題を解決する一環として、管理者が Azure App Service プランの SKU を手動で増やしたとします。 新しい SKU をリソース構成に含めるようにデプロイ テンプレートを更新します。 そうしないと、パイプラインからの次回の定期的なデプロイ中に、SKU が以前の値にリセットされ、再度障害が発生する可能性があります。
Azure 環境に対する変更を監査する
また、Azure 環境全体の監査とログ記録を構成し、特定のイベントや脅威を監視することをお勧めします。
Microsoft Sentinel などのセキュリティ情報イベント管理 (SIEM) ツールの使用を検討してください。 このツールを使用すると、Azure 資産だけでなく Azure DevOps、GitHub、その他のシステムからもログを収集して分析することができます。 Sentinel を使用して、Azure リソースに対する予期しない変更または承認されていない変更を監視できます。 また、パイプラインの監査ログをインポートし、管理者がリポジトリ内のブランチ保護ポリシーを変更したときなど、イベントが発生したときにアラートをトリガーすることもできます。