Azure Security Centerを使ってセキュリティリスクに対策を打つ
はじめに
これまでに2回、Azure Security Centerを使い始めるときに学ぶ内容を書きました。 セキュリティリスクを可視化するところまで来ましたので、今回は見えたリスクにどう手を打つか？という話をしていきます。
おさらい（リスクを特定する）
前回の記事で、設定にリスクのあるリソースは、"規制コンプライアンス"のなかで表示されるという話をしました。どのようなルールに、どれくらいのリソースが違反しているか、一覧で見ることができています。
この例でいえば、「DP.4.Encrypt sensitive information in transit」すなわち「機微情報に対しては通信を暗号化しなさい」と言っています。
見えている範囲では、Web AppsやFunction AppsなどApp Serviceまわりのリソースが怒られていますが、右下のボタンでスクロールさせるとDP.4の通信の暗号化に関する他の項目が見えてきます。（SQLDatabseにはSSLで接続しなければならないとか、TLSのバージョンは最新を使わなければならないとか）
セキュリティリスクに手を打つ
この見えてきたセキュリティリスクへの対応を行います。「通信の暗号化」ができていないリソースに対して、「通信の暗号化」を行わせる設定を施していきます。
手動で修復する
まずは「関数アプリではFTPSを必須とする」を見てみましょう。当該項目を開くと対象の「異常なリソース」の一覧が見えます
この中に「修復の手順」という項目があり、何をすればよいか説明が書いてあります。
修復の手順通り、構成＞全般タブを見ていくと、指摘通り「FTPの状態」が「すべて許可」となっていました。これを「FTPSのみ」に修正して、保存します。
これで手動での対策が出来ました。
半自動で修復する
次に「Web アプリケーションには HTTPS を介してのみアクセスできるようにする」を見てみます。当該項目を開く前に・・・気になるボタンがありますね。
そう！これが表示されている項目は、手順なんて調べることなく、修復してくれるんです。
先回りして対象リソースの設定を見てみると、確かに「HTTPS のみ」がOffになっています。
元々異常なリソースとしては2つカウントされていましたが
リソースを選択して「修復」を押してみると…
一瞬でこうなります。秒です。
念のため、対象リソースの設定を見てみると、こんな感じです！確かにOnになっています。
なお、何されるかわからないから不安、っていう方のために、修復のロジックの説明も記載されていますし、手動での修復手順も説明されています。
Security Centerでの管理のメリット
最大のメリットはこの「修復」にあります。設定違反の検知だけならポリシーでもできるのですが、Security Centerで提供されている規制コンプライアンスの場合、手動／自動の差はあれど「直し方」の説明がちゃんと付いており、簡単な手順でリスクに対策することができます。これでポチポチやっていけば、いつの間にかリスクを低減できるわけですね。
おわりに
今回は、Security Centerで見つけたリスクに対して、具体的にどのように対策をすればよいのかを説明してきました。次に皆さんが考えていることはきっとこうです。「そんなこと言っても、警告がいっぱいありすぎて何から手を付ければいいかわからないよ！」
そんな方のために、次回は優先順位の付け方について説明していきたいと思います。
Discussion