Azure Managed Service Column ＜Azure運用コラム＞Azureでできるアクセス制御Azure Policyとは

はじめに

クラウドを用いたシステムを運用する場合、セキュリティの観点から、各種リソースを必要とする人やシステムからのみ適切にアクセスできる仕組みを作らなければなりません。ただ、適切なアクセス管理を行おうとするとシステムの運用者が管理するものは膨大となり、多大な作業負荷がかかります。

「なぜ適切なアクセス制御が重要なのか？」については、「クラウドセキュリティを担保するために考えるべきことを、クラウド機能の活用例を交えて解説！」もご参照ください。

Azureのアクセス制御に関するサービスには、Azure Policy があります。Azure Policy ではリソースの動作を一括管理できるため、情報システムのセキュリティ強化を図ることが可能です。この記事では、Azure Policy について分かりやすくご紹介します。

1. Azure Policy とは

1.1 Azure Policy の概要

Azure Policy とは、Azure 内に存在するリソースを、ビジネス上のルールに準拠するよう一括管理できるサービスです。Azure では、ポリシーを作成の上端末やサーバーなどのリソースに適用させます。管理の仕組みとしては、Active Directory のグループポリシーと似たようなものと考えるとイメージしやすいのではないでしょうか。なお、Azure Policy の対象となるのはすべての Azure リソースと、Azure Arc 対応のリソースです。

※ Azure Arc：クラウドとオンプレミスのハイブリッド環境を実現するサービス

1.2 Azure Policy でできること

Azure Policy に関する設定は、Azure Portal 上で完結させることが可能です。ルールに違反しているリソースがあれば、それらを一括してルールに準拠した状態にできます。またビジネスルールに違反しているリソースを調査し特定することも、Azure Policy の機能のひとつです。

Azure Policy によって、下記のようなことが実現できます。

• 特定のアプリケーションでパブリックネットワークからのアクセスを無効にする
• 一部の認証方法を無効化する
• セキュリティ強化のためにFTPS 強制を必須にする

など。

2. Azure Policy と Azure RBAC との違いは？

2.1 Azure RBAC とは

Azure RBAC とは、Azure のアクセス制御をロールベースで行えるサービスです。一般に RBAC とは「 Role Based Access Control（ロールベースアクセス制御）」を略した言葉です。Azure RBAC でもロールと呼ばれる、アクセス許可・拒否の権限をまとめたものを用います。

Azure RBAC を使って、あるユーザーに仮想マシンの管理権限を与える、特定のグループでデータベースを管理できるようにする、アプリケーションに対してリソースへのアクセス許可を与える、というようなことが実現可能です。

ロールの作成・カスタマイズを行い、ロールの割り当てを行うなど、操作や概念は Azure Policy と似ています。

2.2 Azure PolicyとAzure RBACとの違いは

Azure Policy と Azure RBAC との違いは、権限を与える対象にあります。 Azure RBAC はユーザーやユーザーグループに対してロールの割り当てを行います。たとえば開発部門のユーザーのみ開発部門のリソースを使用できるように権限を付与する、というようなことができます。

一方 Azure Policy は、リソースやリソースの場所に対して制御を加えるものです。誰がアクセス権限や変更権限をもっているかは問いません。

Azure RBAC については以下の記事で詳しく解説しています。

3. Azure Policy のポリシー定義とポリシー割り当て

Azure Policy の適用は大きく「ポリシー定義」と「ポリシー割り当て」の 2 段階に分けられます。

3.1 Azure Policy を利用するためのツール

Azure Policy は、基本的には Azure Portal を用いて適用させます。PowerShell、Azure CLI などを用いることも可能です。

3.2 ポリシー定義

ポリシーにはおおまかに、リソースに対する規則と、規則が満たされた場合に実行する動作が記述されます。

3.2.1 JSON 形式で記述

ポリシー定義には JSON（ JavaScript Object Notation ）形式が採用されており、JavaScript のコーディング形式にしたがって「表示名」や「パラメータ」などが記述されます。ポリシー内のメインとなる「ポリシーの規則」の部分は、if-then 文を用いた形式で条件と動作が指定される箇所です。形式上の理由から、複雑な条件指定は行いにくいと考えておくのが無難でしょう。

3.2.2 組み込みポリシーの流用も可能

Azure Policy には、標準の組み込みポリシーが用意されており、標準の組み込みポリシーをテンプレートとしてカスタムポリシーを作成することも可能です。標準の組み込みポリシーの詳細はAzureの公式サイトで確認できるほか、GitHub のコミュニティでもサンプルが公開されています。

3.2.3 イニシアチブでグループ化できる

ポリシーはイニシアチブというグループ化を行うこともできます。関連するポリシーをグループ化することで、ポリシーの管理と割り当てが容易になるでしょう。

3.3 ポリシー割り当て

ポリシーを作成した後は、どのポリシーをどのリソースに割り当てるか決めることになります。

3.3.1 適用範囲は「スコープ」が基本

ポリシーの適用下となるリソースの範囲は、「スコープ」と呼ばれます。ポリシー定義を作成した後の最初のスコープは、ポリシー定義を作成した場所によって決定します。サブスクリプションで作成するとそのサブスクリプション全体、特定のリソースや管理グループで作成するとリソースや管理グループがスコープとなるのです。

その後は目的のリソースやリソースグループ、サブスクリプション、管理グループをスコープとしたり除外したりすることが可能です。

3.3.2 JSON 形式で割り当てを作成

ポリシー定義と同様、ポリシーの割り当ての作成にも JSON を用います。「表示名」や「パラメータ」を記述するほか、有効・無効の「適用モード」の指定を行うことになります。「適用モード」の無効のパラメータはまったく無効になるわけではなく、特定の評価（ DeployIfNotExists ）の対象であり、必要があればリソースの修復を行えるものです。

3.4 リソースが評価されるタイミング

リソースがポリシーによって評価されるタイミングは、標準では 24 時間ごとです。他に下記のように、ポリシー定義や割り当てに変更があった場合にも評価されます。

• ポリシーやイニシアチブが新たに作成されたとき
• ポリシー割り当てが新たに行われたとき
• 割り当てられているポリシーやイニシアチブが更新・削除されたとき
• ポリシー割り当てに変更・削除があったとき

4. 注意事項

ポリシー定義ではカスタムポリシーを作成できるものの、情報システムの規模によっては、どこまでどう適用するか、設計が複雑になるケースもあります。開発・運用両面のコストを考えると、カスタムポリシーはシンプルで適切な形に設計するのが理想的です。

5. Azure Policy の価格

Azure リソース内での Azure Policy の使用には追加料金はなく、無料です。サービスが無料であることから、返金制度のある SLA （品質保証レベル）も設定されていません。

Azure Policy の価格詳細については、公式サイトをご確認ください。

6. まとめ

今回は、Azure Policy についてご紹介しました。

Azure Policyでは、Azure Portal 上で作業を完結させることも可能で、運用負荷の軽減を図れます。企業の情報セキュリティ施策のひとつとして、ご活用を検討してみてはいかがでしょうか。

Tag： Azure Policy セキュリティ

• 

  クラウドセキュリティを支える重要な機能「HSM」とは？

• 

  Azure Bot Serviceとは？ボットアプリの基礎知識とAzure Bot Serviceの概要と特徴を解説