クラウドエンジニアブログ

SQL Database のセキュリティシナリオ

human05

古林

みなさまこんにちは。今回初めてブログを書くことになりました、クラウドアーキテクトの卵です。まだまだ新米ですが、できるだけ読みやすい記事にしていきたいと思っていますので、どうぞよろしくお願いいたします。

はじめに

今回は私の興味分野の1つである、PaaS としてサービス提供されている SQL Database のセキュリティ対策について紹介いたします。

一般に、データベースについてはデータの格納場所となるため、より強力なセキュリティを求められることが多いのではないでしょうか。一昔前に比べ、外部からの攻撃だけでなく、内部からの情報漏えい等への意識が高いお客様も増えてきたと感じています。特に個人情報を扱う場合、昨今はとても敏感にならざるを得ません。

とあるお客様のコンサルティング案件をお手伝いした際に、Azure のセキュリティ対策についてまとめたことがあります。今回はその経験をベースに私が実際の SI 案件で採用した SQL Database 部分のセキュリティ対策をその判断を交えてご紹介します。


SQL Database のセキュリティに関するベストプラクティス

SQL Database のセキュリティについては、Microsoft の公開ドキュメントに推奨事項(ベストプラクティス)がまとめられています。類似のページはいくつかありますが、今回は以下のリンクをベースにします。

参考: Azure のデータベース セキュリティに関するベスト プラクティス

SQL Database で提供されているセキュリティ対策を表にまとめると以下の通りとなります。以降、表のカテゴリごとにベストプラクティスについて記載します。

左右にスクロールしてご覧ください。

No. カテゴリ ベストプラクティス
1 通信制御 ファイアウォール(サーバーレベル)
2 ファイアウォール(データベースレベル)
3 認証 データベース認証
4 暗号化 Transparent Data Encryption(TDE)
5 Always Encrypted
6 監査 SQL Database の監査
7 SQL Database の脅威の検出


通信制御

通信制御はネットワークレベルのアクセス制御のことを示します。ネットワークレベルのアクセス制御はファイアウォールが有名ですが、SQL Database でもファイアウォールを使用します。SQL Database に使用できるファイアウォールは、以下の 2種類です。

  1. サーバーレベルのファイアウォール
  2. データベースレベルのファイアウォール
上記2つのファイアウォールを図に表すと以下のようなイメージとなります。

ファイアウォール


1. サーバーレベルのファイアウォール

クライアント IP アドレスからのアクセスをデータベースサーバーレベルで許可します。古くからオンプレミスの SQL Server でも実施されてきた方法であるため、馴染みが深い方法であると思います。
クライアント IP アドレスの他に、Azure 上の特定の仮想ネットワーク(VNet)内にあるサブネットからのみ、通信を許可することも可能です。サブネットにサービスエンドポイント(※)を設定し、サーバーレベルのファイアウォール側でサービスエンドポイントを設定したサブネットを指定するだけで OK です。

※ サービスエンドポイントとは、Azure サービス リソースへのアクセスを仮想ネットワークのみに限定することができる機能です。

参考: 仮想ネットワーク サービス エンドポイント

これまで私が対応した案件では、ほとんどのケースでサーバーレベルのファイアウォールで通信制御を実施する方法を採用していました。

2. データベースレベルのファイアウォール

データベースレベルのファイアウォールは、データベースサーバー内にあるデータベース単位での通信制御機能を提供します。サーバーレベルのファイアウォールを構成した後に構成します。SQL Server Management Studio から構成可能です。ただし、SQL Database がマルチテナントであった場合、ストアドプロシージャから実行しないと実施できない点に注意が必要です。

しかし、私の経験では未だにデータベースレベルのファイアウォールを使用したことはありません。(おそらく、システム毎にデータベースサーバーを分けるお客様が多いため、データベースレベルでファイアウォールを設定する必要性がなかったことがその理由ではないかと思います。)

認証

認証は下記の2種類の方法をサポートしています。SQL Server で使用できる Windows 認証は、SQL Database ではサポートしていないので注意が必要です。

  1. SQL 認証
  2. Azure Active Directory 認証(Azure AD 認証)

1. SQL 認証

SQL Server で言う、SQL Server 認証と同じです。データベース単位でのユーザー名とパスワードを指定する、おなじみの方法です。

私の経験では、これまで外部に公開する Web アプリケーションの案件が多かったため、SQL Database の認証は SQL 認証一択でした。Web アプリケーションで SQL 認証を使用する場合、アプリケーションが使用するユーザー名とパスワードを管理すれば良いため、データベース上でのユーザー管理はそれほど手間ではありませんでした。

また、接続文字列は config ファイル等に外出しして記載することが通例であるので、ベストプラクティスのリンクに記載されている「強力な資格情報を自分で管理」「接続文字列で資格情報を保護」は守られていたと考えます。

2. Azure Active Directory 認証(Azure AD 認証)

SQL Database への接続に Azure AD の ID を使用できる認証方式です。他の Microsoft サービスと一元管理を行うことが可能です。

SQL Database で Azure AD 認証が可能であることは、調べるまで分かりませんでした。直接使用したことはないのですが、社内のポータルサイトのような Web アプリケーション ではユーザー管理の手間を削減できそうです。

例えば、Azure AD グループごとにデータベースユーザーを作成し、そのデータベースユーザーに SQL Database のロールを付与することで、Azure AD グループ単位で SQL Database の権限管理が可能となります。これにより、「ある Azure AD グループに所属しているユーザーのみが、このテーブルにアクセス可能」といった、Azure AD グループをベースにした権限管理が実現できます。

暗号化

データ保護の観点から採用されるセキュリティ対策について、よく用いられる対策として暗号化が挙げられます。現状、SQL Database の主な暗号化技術として、以下2つが挙げられます。

  1. Transparent Data Encryption(TDE)
  2. Always Encrypted
「ん?どうして SQL Database の暗号化技術は 2つあるの?何が違うの?」「どちらか片方を使用するの?」と疑問を感じた私みたいな人もいるかもしれません。

上記 2つの暗号化技術の使い分けについて、『【定期便】9/3 週 Azure の公開情報まとめ』に SQL Database または SQL Server で適切な暗号化技術を選択する方法が紹介されていました。

参考:Transparent data encryption or always encrypted?(英語)
参考:透過的なデータ暗号化と Always Encrypted(上記URLの翻訳版)

TDE と Always Encrypted の違いについては上記リンクにある図が分かりやすいと思いますが、もっとシンプルに表すと以下のようなイメージになります。

ファイアウォール


1. Transparent Data Encryption(TDE)

Transparent Data Encryption(TDE)は、データベース自体の暗号化です。
AES 暗号化アルゴリズムを使用してデータベース全体を暗号化します。ざっくり言ってしまうと、データベースの基となるデータファイル、ログファイル、バックアップファイルに対し、暗号化を実施します。暗号化のキーはデータベースサーバーのマスターデータベースに保存されている証明書を使用するサービス管理キー、EKM モジュールや Azure Key Vault で保護されている非対称キーを使用するユーザー管理キーが選択可能です。

TDE は日本語で「透過的なデータ暗号化」と訳されるように、既存のアプリケーションの変更なく、入出力データをリアルタイムで暗号化・複合化できる点が魅力です。また、以下の場合でも暗号化の状態が引き継がれます。

  • Geo レプリケーション
  • ポイント イン タイム復元
  • 削除されたデータベースからの復元
  • データベースのコピー

1つ注意があるとすれば、bacpac ファイルや bcp コマンドでエクスポートされたデータについては暗号化されません。そのため、機密データを扱う際には、データ自体の暗号化が必要になります。

TDE を利用する場合、サーバー製品として提供されている SQL Server では Enterprise Edition が必要ですが、PaaS で提供される SQL Database ではプランによる制限はないようです。(3年程前は SQL Database の P シリーズ(Premium)でないと使えませんでした。現在、マイクロソフトが提供する公開情報からは、その記載が削除されているように見受けられます。)

2. Always Encrypted

Always Encrypted はデータベース内のデータに対してクライアント側で暗号化をします。ざっくり言ってしまうと、テーブルのカラム(列)のデータに対して暗号化を実施します。演算処理やメモリ内での処理が実行されている間も、データを暗号化しておくことが可能であるため、SQL Server がメモリ スキャン攻撃を受けた場合やメモリ ダンプ ファイルからデータを抽出された場合であってもデータそのものは保護されます。
クライアント側の暗号化処理に使用されるキーは SQL Database に公開されることはありません。

クライアント側で暗号化し、実データだけでなくメモリ内のデータまで暗号化されるので、セキュリティ対策としては非常に強力です。

ただ、カラムレベルの暗号化はアプリケーション側で実施されることがほとんどでした。(Always Encrypted が実装されたのが SQL Server 2016 以降と最近であることもその一因と考えられます。)

カラムデータの暗号化という点で言えば、Always Encrypted を利用してもアプリケーションでの実行としても、どちらでも良いと思います。強いて言えば、既存アプリケーションで暗号化を行っているシステムの Azure 移行の場合には、そのまま既存アプリケーションでの暗号化を継続し、Azure 上に SQL Database、または SQL Server で新規システムを構築する場合には Always Encrypted を利用するのが、構築コストの点で良いと考えられます。

監査

SQL Database の監査については、以下2つが挙げられます。

  1. SQL Database の監査
  2. SQL Database の脅威の検出

1. SQL Database の監査

監査証跡をオンにすることで、SQL Database データベースエンジンで発生するイベントを追跡し、ログに記載します。監査証跡を残すことで、データベースでどのような処理が、「誰」によって「いつ」実施されたのかを確認でき、セキュリティ コンプライアンス要件への対応が可能になります。また、データ関連の不具合や異常を確認することでセキュリティ インシデントの特定が可能になります。

データベースの監査はおなじみの機能かと思います。無償で利用可能です。SQL Database では Azure Portal より設定可能です。細かい設定は PowerShell で行うことになります。このあたりが SQL Server との違いです。

2. SQL Database の脅威の検出

データベースに対する異常なアクティビティを検知し、指定したメールアドレスにアラートを送信します。異常なアクティビティとして、以下を検出可能です。

  • SQL インジェクション
  • SQL インジェクションの脆弱性
  • 異常なクライアント ログイン

脅威検出の方法(ルール)は、以下2つです。

  • 確定的な検出
    → ルールベース。既知の攻撃に有効。
  • 動作検出
    → 過去30日間に見られなかった異常なアクティビティを検出。

Azure Portal の[監査ログ]ブレードより簡単に設定・閲覧することができる点は手間がかからずセキュリティ対策ができる点で良いと思います。

お手軽にデータベース監査ができる機能ですが、SQL Database の脅威の検出を利用するにあたって、2点注意事項があります。
1点目として、SQL Database の脅威の検出は、アラートとして通知するのみの機能です。WAF のように脅威をブロックするような機能はありません。

2点目として、SQL Database の脅威の検出機能は、外部からの攻撃や内部の脅威から包括的にシステム・サービスを保護するクラウドサービスである Advanced Threat Protection(ATP)を使用しています。最初の 60日は無償利用可能ですが、それ以降は別途費用が発生します。

おわりに

実は上記で述べた他に、ベストプラクティスについてもう1点…「転送中のデータを保護する」という項目があります。これは常時 SSL / TLS プロトコルを使用してデータをやり取りすることを推奨するという内容ですが、転送中のデータ保護については SQL Database に限った話ではないので、ここでは割愛しています。

SQL Database はオンプレミスの SQL Server で実施してきたセキュリティ対策がほぼそのまま使えるので、それほど学習コストがかからず SQL Database のセキュリティ対策が可能です。また、Microsoft がクラウドファーストを掲げているだけあって、最新の機能は SQL Database に実装され、機能が固まった段階で SQL Server にフィードバックするという開発方針であることも宣言されており、欲しい機能が利用可能になったらすぐ提案、使用できるという点も魅力です。

SQL Database のセキュリティ対策については、以下のリンクも参考になりますので、あわせてご参照ください。比較的最新の情報が記載されている、かつ、具体的な設定手順が記載されています。

参考: Azure SQL データベースのセキュリティ保護



次回予告
  • サービスエンドポイントポリシーによる特定リソースへのアクセス許可



【総合】お問い合わせ

ソリューションに関する全般的なお問い合わせはお気軽にご相談ください。

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録