👮

Azureポリシーは「組み込みポリシー」を使うべきか、「カスタムポリシー」を書くべきか

2021/08/10に公開

Azure

policy

tech

はじめに

Azureポリシーには、Azureが提供するマネージドなポリシー（組み込みポリシー）に加えて、自分で好きに制御項目を書くことができる「カスタムポリシー」という考え方があります。
※Azureポリシーとは、という観点で基本の考え方を書いた記事もありますので、Azureポリシーよくわからんけどって場合はこちらをご参照ください。

カスタムポリシーでは名称、条件、他色々細かく書けるので、とても便利に使えるような気がするのですが、今回は『出来るだけ「組み込みポリシー」を使った方が良いよ』という話を、自分がハマった実例混じりで紹介しようと思います。

ハマった事象

前提

私の見ている環境では、Azureポリシーを使ってクラウド的な甘い設定不備に気付けるようにしています。基本的には「Azure Security Standard」に出てくるポリシーを設定しているのですが、

より厳しく見たりルールの修正が必要だったりすることもあるので、カスタマイズしたポリシーを使っています。
※今回書くような課題に直面することもあるので、本来はSecurityCenterを有効化することで自動的に適用されるイニシアチブをそのまま使う方が良いと思います。。

事象

2021年7月上旬、↓で紹介されている「Transparent Data Encryption on SQL databases should be enabled」に対応したポリシーが、「設定違反」を報告してくるようになりました。

対象リソースは、既存のSQLDatabase全てで、もちろん新しく作成したリソースでも無ければ、TDEの設定変更（設定解除）もしていません。
ということでAzureサポートに質問し、解決策を確認しました。

原因

直接的な原因としては、SQLDatabse側のパラメータの持ち方が変わり、当初のポリシーではパラメータの検査が出来なくなったためでした。2021年7月末時点では、すでに組み込みポリシーも更新されており、組み込みポリシーをそのまま使っている方は問題は収束していると思われます。

※変更点詳細は、「history」を見ると分かります。

変わったコト

ポリシーがどのように変更されたか、すなわちSQLDatabseのデータの持ち方がどう変わったか、少し深堀してみてみます。
なお、ルールの読み方は下記の記事にまとめてますのでこちらも見ていただければと思います。(2021/8/11 リンクにミスがあったので訂正)

旧ポリシー（抜粋）

"policyRule": {
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Sql/servers/databases"
      },
      {
        "field": "name",
        "notEquals": "master"
      }
    ]
  },
  "then": {
    "effect": "AuditIfNotExists",
    "details": {
      "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
      "name": "current",
      "existenceCondition": {
        "allOf": [
          {
            "field": "Microsoft.Sql/transparentDataEncryption.status",
            "equals": "enabled"
          }
        ]
      }
    }
  }
}

新ポリシー（抜粋）

"policyRule": {
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Sql/servers/databases"
      },
      {
        "field": "name",
        "notEquals": "master"
      }
    ]
  },
  "then": {
    "effect": "AuditIfNotExists",
    "details": {
      "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
      "name": "current",
      "existenceCondition": {
        "anyOf": [
          {
            "field": "Microsoft.Sql/transparentDataEncryption.status",
            "equals": "enabled"
          },
          {
            "field": "Microsoft.Sql/servers/databases/transparentDataEncryption/state",
            "equals": "enabled"
          }
        ]
      }
    }
  }
}

変更箇所を見ると、新ポリシーの方では従来の条件に加えて
"Microsoft.Sql/servers/databases/transparentDataEncryption/state"
という新しいパラメータが「enabled」であることをチェックするようになっています
　※AnyOfなので、どちらかがEnabledならOK
サポートの方によれば、従来のパラメータである
"Microsoft.Sql/transparentDataEncryption.status"
の条件判定は既に不要とのことですが、移行時の一時的な名残として残っているようです。

教訓

Azureの仕様変更により、ポリシーが効かなくなるということがありえます、というハマりポイントでした。
今回は、「判定できなくなったので、必ず設定違反が報告される（false positive/疑陽性）」という動き方だったため更新に気付けましたが、場合によっては「判定できなくなったので、設定違反が報告されなくなった（false negative/疑陰性）」となってしまう可能性もあります。
Azureポリシーという統制・ガバナンスに用いるサービスですので、できるだけ疑陰性は無くしたいものですが、パブリッククラウドという特性上、どうしてもゼロに抑えることは出来ないと思われます。
カスタマイズポリシーを使ってしまうと、そこの検出の仕組みも自分で作らなければならない（かならず違反が報告されるリソースを作って、その違反が止まったら異常だと気づかなければいけない）ことになるため、出来る限り組み込みポリシーを使って、Azure側の更新に任せましょう…

おわりに

Azureポリシーを使いこなしてたと思ったらカスタムポリシーでハマった話を書きました。
自分がハマった話なので誰かの役に立つかは微妙ですが、同じようにカスタムポリシーでブイブイ言わせている方は気を付けてみてください。

はじめに

ハマった事象

前提

事象

原因

変わったコト

教訓

おわりに

Discussion