みなさまこんにちは。今回初めてブログを書くことになりました、クラウドアーキテクトの卵です。まだまだ新米ですが、できるだけ読みやすい記事にしていきたいと思っていますので、どうぞよろしくお願いいたします。
今回は私の興味分野の1つである、PaaS としてサービス提供されている SQL Database のセキュリティ対策について紹介いたします。
一般に、データベースについてはデータの格納場所となるため、より強力なセキュリティを求められることが多いのではないでしょうか。一昔前に比べ、外部からの攻撃だけでなく、内部からの情報漏えい等への意識が高いお客様も増えてきたと感じています。特に個人情報を扱う場合、昨今はとても敏感にならざるを得ません。
とあるお客様のコンサルティング案件をお手伝いした際に、Azure のセキュリティ対策についてまとめたことがあります。今回はその経験をベースに私が実際の SI 案件で採用した SQL Database 部分のセキュリティ対策をその判断を交えてご紹介します。
SQL Database のセキュリティについては、Microsoft の公開ドキュメントに推奨事項（ベストプラクティス）がまとめられています。類似のページはいくつかありますが、今回は以下のリンクをベースにします。
参考： Azure のデータベース セキュリティに関するベスト プラクティス左右にスクロールしてご覧ください。
| No. | カテゴリ | ベストプラクティス |
|---|---|---|
| 1 | 通信制御 | ファイアウォール（サーバーレベル） |
| 2 | ファイアウォール（データベースレベル） | |
| 3 | 認証 | データベース認証 |
| 4 | 暗号化 | Transparent Data Encryption（TDE） |
| 5 | Always Encrypted | |
| 6 | 監査 | SQL Database の監査 |
| 7 | SQL Database の脅威の検出 |
通信制御はネットワークレベルのアクセス制御のことを示します。ネットワークレベルのアクセス制御はファイアウォールが有名ですが、SQL Database でもファイアウォールを使用します。SQL Database に使用できるファイアウォールは、以下の 2種類です。
クライアント IP アドレスからのアクセスをデータベースサーバーレベルで許可します。古くからオンプレミスの SQL Server でも実施されてきた方法であるため、馴染みが深い方法であると思います。
クライアント IP アドレスの他に、Azure 上の特定の仮想ネットワーク（VNet）内にあるサブネットからのみ、通信を許可することも可能です。サブネットにサービスエンドポイント（※）を設定し、サーバーレベルのファイアウォール側でサービスエンドポイントを設定したサブネットを指定するだけで OK です。
※ サービスエンドポイントとは、Azure サービス リソースへのアクセスを仮想ネットワークのみに限定することができる機能です。
参考：
仮想ネットワーク サービス エンドポイント
これまで私が対応した案件では、ほとんどのケースでサーバーレベルのファイアウォールで通信制御を実施する方法を採用していました。
データベースレベルのファイアウォールは、データベースサーバー内にあるデータベース単位での通信制御機能を提供します。サーバーレベルのファイアウォールを構成した後に構成します。SQL Server Management Studio から構成可能です。ただし、SQL Database がマルチテナントであった場合、ストアドプロシージャから実行しないと実施できない点に注意が必要です。
しかし、私の経験では未だにデータベースレベルのファイアウォールを使用したことはありません。（おそらく、システム毎にデータベースサーバーを分けるお客様が多いため、データベースレベルでファイアウォールを設定する必要性がなかったことがその理由ではないかと思います。）
認証は下記の2種類の方法をサポートしています。SQL Server で使用できる Windows 認証は、SQL Database ではサポートしていないので注意が必要です。
SQL Server で言う、SQL Server 認証と同じです。データベース単位でのユーザー名とパスワードを指定する、おなじみの方法です。
私の経験では、これまで外部に公開する Web アプリケーションの案件が多かったため、SQL Database の認証は SQL 認証一択でした。Web アプリケーションで SQL 認証を使用する場合、アプリケーションが使用するユーザー名とパスワードを管理すれば良いため、データベース上でのユーザー管理はそれほど手間ではありませんでした。
また、接続文字列は config ファイル等に外出しして記載することが通例であるので、ベストプラクティスのリンクに記載されている「強力な資格情報を自分で管理」「接続文字列で資格情報を保護」は守られていたと考えます。
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つが挙げられます。
Transparent Data Encryption（TDE）は、データベース自体の暗号化です。
AES 暗号化アルゴリズムを使用してデータベース全体を暗号化します。ざっくり言ってしまうと、データベースの基となるデータファイル、ログファイル、バックアップファイルに対し、暗号化を実施します。暗号化のキーはデータベースサーバーのマスターデータベースに保存されている証明書を使用するサービス管理キー、EKM モジュールや Azure Key Vault で保護されている非対称キーを使用するユーザー管理キーが選択可能です。
TDE は日本語で「透過的なデータ暗号化」と訳されるように、既存のアプリケーションの変更なく、入出力データをリアルタイムで暗号化・複合化できる点が魅力です。また、以下の場合でも暗号化の状態が引き継がれます。
Always Encrypted はデータベース内のデータに対してクライアント側で暗号化をします。ざっくり言ってしまうと、テーブルのカラム（列）のデータに対して暗号化を実施します。演算処理やメモリ内での処理が実行されている間も、データを暗号化しておくことが可能であるため、SQL Server がメモリ スキャン攻撃を受けた場合やメモリ ダンプ ファイルからデータを抽出された場合であってもデータそのものは保護されます。
クライアント側の暗号化処理に使用されるキーは SQL Database に公開されることはありません。
クライアント側で暗号化し、実データだけでなくメモリ内のデータまで暗号化されるので、セキュリティ対策としては非常に強力です。
ただ、カラムレベルの暗号化はアプリケーション側で実施されることがほとんどでした。（Always Encrypted が実装されたのが SQL Server 2016 以降と最近であることもその一因と考えられます。）
カラムデータの暗号化という点で言えば、Always Encrypted を利用してもアプリケーションでの実行としても、どちらでも良いと思います。強いて言えば、既存アプリケーションで暗号化を行っているシステムの Azure 移行の場合には、そのまま既存アプリケーションでの暗号化を継続し、Azure 上に SQL Database、または SQL Server で新規システムを構築する場合には Always Encrypted を利用するのが、構築コストの点で良いと考えられます。
SQL Database の監査については、以下2つが挙げられます。
監査証跡をオンにすることで、SQL Database データベースエンジンで発生するイベントを追跡し、ログに記載します。監査証跡を残すことで、データベースでどのような処理が、「誰」によって「いつ」実施されたのかを確認でき、セキュリティ コンプライアンス要件への対応が可能になります。また、データ関連の不具合や異常を確認することでセキュリティ インシデントの特定が可能になります。
データベースの監査はおなじみの機能かと思います。無償で利用可能です。SQL Database では Azure Portal より設定可能です。細かい設定は PowerShell で行うことになります。このあたりが SQL Server との違いです。
データベースに対する異常なアクティビティを検知し、指定したメールアドレスにアラートを送信します。異常なアクティビティとして、以下を検出可能です。
実は上記で述べた他に、ベストプラクティスについてもう1点…「転送中のデータを保護する」という項目があります。これは常時 SSL / TLS プロトコルを使用してデータをやり取りすることを推奨するという内容ですが、転送中のデータ保護については SQL Database に限った話ではないので、ここでは割愛しています。
SQL Database はオンプレミスの SQL Server で実施してきたセキュリティ対策がほぼそのまま使えるので、それほど学習コストがかからず SQL Database のセキュリティ対策が可能です。また、Microsoft がクラウドファーストを掲げているだけあって、最新の機能は SQL Database に実装され、機能が固まった段階で SQL Server にフィードバックするという開発方針であることも宣言されており、欲しい機能が利用可能になったらすぐ提案、使用できるという点も魅力です。
SQL Database のセキュリティ対策については、以下のリンクも参考になりますので、あわせてご参照ください。比較的最新の情報が記載されている、かつ、具体的な設定手順が記載されています。
参考：
Azure SQL データベースのセキュリティ保護
