1. はじめに
Microsoft Defender for Cloud では Azure SQL データベースに対して脆弱性評価する機能が提供されています。Microsoft Defender for SQL を有効にすると検知され、推奨事項で確認が出来るようになりますが、この脆弱性の内容や運用方法についてご紹介いたします。
参考 Microsoft Defender for SQL による脆弱性評価
Microft Defender For Cloud では、Azure SQL データベース PaaS サービスや、Azure/AWS/GCP/オンプレミスの IaaS SQL サーバーに対して Defender for SQL を提供しています。IaaS に対しては Azure Arc をオンボーディングして接続するような構成です。
2. 設定の有効化 / Micsosoft Defender for SQL
設定の有効化はサブスクリプション単位で有効化する方法と、リソースレベルで有効化する二通りがあります。リソースによって異なるので注意が必要です。
3. 検知画面
SQL サーバー/サービスの脆弱性情報はリソースの情報、もしくは Microsoft Defender For Cloud の推奨事項「SQL データベースでは、脆弱性の検出結果が解決されている必要がある」から確認が取れます。
- Azure SQL データベース
- Microsoft Defender For Cloud
ここまでは Defender for SQL を有効化されたことがある方は経験があるのではと思いますが、ここで検知する VAxxxx なる脆弱性って何？って話になってきます。。
4. 改めて、Microsoft SQL の脆弱性って何か
「脆弱性」と聞くと、OS に発生する脆弱性 ID やパッチ適用の運用のように思いますが、Microsoft SQL の脆弱性はベストプラクティスからの逸脱を検知するためのルールです。以下ドキュメントからの抜粋です。
脆弱性評価は、Azure SQL Database に組み込まれているスキャン サービスです。 このサービスでは、セキュリティの脆弱性にフラグを付ける規則のナレッジ ベースが採用されています。 これは、誤った設定、過剰なアクセス許可、保護されていない機密データなど、ベスト プラクティスからの逸脱を明らかにします。
規則は Microsoft のベスト プラクティスに基づき、データベースとその貴重なデータにとって最も大きなリスクとなるセキュリティの問題に注目します。 データベース レベルの問題と、サーバーのファイアウォール設定やサーバー レベルの権限などのサーバー レベルのセキュリティ問題がカバーされます。
VAxxxx から始まる脆弱性の検出 ID は以下にリストが掲載されています。2023.4 現在、以下の5つのカテゴリーに分類されています。
この Microsoft SQL 脆弱性評価は SQL サーバー 2012 以降の SSMS (SQL Server Management Studio) でも機能として提供されており、歴史が長いものになっています。
参考 Microsoft SQL サーバー ベストプラクティス
Microsoft SQL 脆弱性管理の元となるベストプラクティスについては、以下 Docs を参照下さい。
5. ベースラインを作るべし / 最初は全て誤検知から始まる！
検出した脆弱性情報の内容を見ると、「ベースラインを作って下さい」なる言葉が出てきます。。
慌てずに、データベースや脆弱性情報を確認すると、ベストプラクティスのルールから逸脱したユーザーや IP アドレスなどの情報を確認することが出来ます。ここで、企業ポリシーで必要となるユーザーや IP アドレスが正しく許可された情報として設定されるように 「すべての情報をベースラインとして追加」 することが出来ます。
逆に言えば、最初はユーザーなどの情報が何も考慮されていないため、誤検知として検出されるので、まず自社用のポリシーを適用しないとダメなんですね。。
ベースラインを追加する際に確認メッセージが表示されます。登録したアセット情報は以後スキャン対象外になることが分かります。
ベースラインとして登録すると、検出した脆弱性 ID が「正常」に戻ることが分かります。
以下の例では、管理者のユーザーと SQL Database でクラウド側で設定される sa ユーザーだったので除外することにしました。
一度ベースラインとして登録した情報は「合格」したリストから確認が出来ます。
同様に、VA2065 Server-level firewall rules should be tracked and maintained at a strict minimum のベースライン設定例を挙げてみます。
本ルールはベストプラクティスである SQL サーバーのネットワーク設定として Firewall ルールを設定せよといったものになります。
ネットワークの設定はサービスエンドポイントを有効化し、グローバルからは自宅 IP だけを許可した検証環境でした。
VA2065 の脆弱性はサーバーレベルの firewall ルールを最小限に抑えるべし、といった脆弱性なので、自宅からの Firewall Rule Name : myhome と、「Azure サービスおよびリソースにこのサーバーのアクセスを許可する」オプションの AllowAllWindowsAzureIps をベースラインとして許可しています。
AllowAllWindowsAzureIps については以下 Docs をご参照下さい。
6. ルール毎の除外設定
SQL 脆弱性 ID に対して、個々の VAID や重大度に応じて除外設定を定義することも出来ます。
軽微なベストプラクティスを対象外として設定する場合は、「ルールの無効化」より除外設定を行ってください。
設定した除外ルールは、当画面の管理グループ階層を右クリックすることで再表示・削除することが出来ます。
無効化ルール自体は一つしか登録することができませんが、除外対象とする ID はセミコロン区切りで複数の ID を設定することが可能です。
例：VA1234;VA5678
7. 除外設定のサマリー
Microsoft Defender for Cloud の SQL 脆弱性の監査を除外する方法をサマリーでまとめると、以下のようになります。
表でまとめる以下のようになります。上段の方が強い除外方式となります。
| 除外方式 | 説明 |
|---|---|
| ポリシーの適用除外 | MDC による SQL 脆弱性評価そのものを除外する |
| 無効化ルール | 脆弱性 VAID、重要度(Severity)、コンプラアンス(VAIDに紐づく、SOX など)でルールを除外する |
| ベースライン | 脆弱性で検知したアセット(IP、ユーザー名など)に対してベースラインを作成して除外する |
7. まとめ
SQL サーバーの脆弱性を有効化されている方は多いと思いますが、検出したままで放置してしまうこともあるのではと思います。用いる構成をベースラインとして登録し、逸脱した設定を検知してセキュアな SQL データベース環境を構築するヒントにしていただければと思います。本記事がどなたかの参考になれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。