このページの本文へ

前へ 1 2 3 次へ

プロに教わるAzure設計運用のベストプラクティス 第4回

「Azure SQL Database」を中心に据え、データを多層的に保護する手法を検討する

あらゆる観点から考える「データセキュリティ」のベストプラクティス

2021年08月30日 08時00分更新

文● 平山 理/日本マイクロソフト 編集● 大塚/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 Microsoft Azureの設計運用ベストプラクティスを紹介している本連載。4回目の今回は「データの保護」について取り上げる。オンプレミスで運用してきたシステムをAzureに移行するにあたって(あるいはAzure上で新規にシステムを開発するとしても)、最も大きな懸念事項のひとつはデータの安全性をいかに担保するか、という点であると言える。

 本稿では、Azureの中で最も利用されているデータベースサービスのひとつである「Azure SQL Database」を例にとり、さまざまな観点からデータのセキュリティを高める方策を紹介する。

アクセス経路を完全に保護する

 Azure上にデータを格納した場合、その利用場所(企業内のクライアントなど)と格納先であるAzure SQL Database内とのデータのやり取りには、当然のことながらネットワークを介したアクセスが発生することになる。まずは、ネットワークを介して安全にデータの送受信を行うための手段を、その利用状況別に2つのパターンで紹介する。

 「Azure Private Link」は、Azure内のネットワーク通信を安全に行うためのサービスのひとつである。Azure Private Linkを利用することによって、仮想ネットワーク内のPrivate IPアドレスを介したAzure SQL Databaseとの接続の確立が可能になり、両者の通信にはMicrosoftのバックボーンネットワークが使用される。

 Azure Private Linkは2つの主要コンポーネントで構成されており、その一方は「Private Endpoint」である。これはクライアントが所属する仮想ネットワークに作成するネットワークインターフェースであり、同仮想ネットワーク内のPrivate IPアドレスが割り当てられる。

 もう一方の構成要素は「Private Linkサービス」である。接続対象となるサービス(本稿ではAzure SQL Database)と、任意の仮想ネットワークに作成したPrivate Endpointをリンクさせることにより、同仮想ネットワークに所属する接続クライアントとのPrivate IPアドレス経由での接続を可能にする。これらのコンポーネントを利用してAzure Private Linkを使用すると、パブリックなエンドポイントなどを介することなく、セキュアな通信が実現できる。

●Azure外との通信が必要な場合 ― ExpressRoute

 Azure SQL Databaseに格納されたデータの利用場所は、Azure内には限定されない。例えば自社内のオンプレミス環境からのAzure SQL Database内のデータ参照などは、ごく一般的な要求と言える。そのような場合において、Azure SQL Databaseとデータを利用する拠点を結ぶネットワークの安全性を向上させる手段の筆頭として挙げられるのは、「ExpressRoute」の「Microsoftピアリング」の利用である。インターネットを経由することなく専用線で両者を接続できるため、非常に高くセキュリティを保つことができる(詳しくは本連載第2回を参照いただきたい)。

★アクセス経路を完全に保護するためのベストプラクティス

●Azure Private Linkを活用してAzure内の通信を保護
●オンプレミス環境などとの通信の保護にはExpressRouteの利用を検討

格納中はもとより転送中のデータも暗号化

 オンプレミス、クラウドを問わず、データ暗号化はデータ保護のための必須の機能といえる。また、データを格納するデータベース自体の暗号化はもとより、ネットワーク転送中にもデータが暗号化されていることがセキュリティ上重要な条件となる。

 Azure SQL Databaseをデータストアとして利用することによって、双方の暗号化がデフォルトで実施される。特に意識することなくデータが保護されるので、利用者は安心して使用することができる。

●ネットワーク転送中の暗号化 ― トランスポート層セキュリティ(TLS)

 Microsoftが提供している(あるいはサポートしている)すべてのドライバーで、トランスポート層セキュリティ(TLS:Transport Layer Security)が使用されている。それらを使用することによって、Azure SQL Databaseへアクセスする際には、すべての接続でネットワーク転送中のデータが暗号化されることになる。

 一方で、Microsoft製ではない(あるいはサポートされていない)ドライバーを接続に使用すると、TLSが使用されない可能性がある。そのようなドライバーを、パッケージソフトやアプリケーションの動作仕様によって選択する必要がある場合は、セキュリティ保護状況を入念に確認することを推奨する。特に、機密度の高い重要なデータが含まれる場合は厳重な注意が必要だ。

 さらにセキュリティを強化するために、Azure SQL Databaseではクライアントに許可する最小レベルのTLSを指定することができる。現在この機能でサポートされている指定値は、TLS 1.0、1.1、1.2となっている。例えばTLS 1.1を指定した場合は、TLS 1.1以降を使用したクライアントからの接続のみを受け付け、TLS 1.0のクライアントからの接続要求は次のメッセージと共に拒否される。

 Error 47072
 Login failed with invalid TLS version

●データベースの暗号化 ― 透過的データベース暗号化

 Azure SQL Databaseでは、格納状態のデータを保護するために「透過的データベース暗号化(TDE:Transparent Database Encryption)」によって、データベースファイル、トランザクションログファイル、バックアップファイルの暗号化が行われる。これによって悪意のあるオフライン操作(データの持ち出しなど)からのデータ保護が可能になる。暗号化に関する処理はすべてバックエンド側で自動的に行われるため、利用者が意識することはなく、アプリケーションの改修なども必要ない。

 TDEでは「データベース暗号化キー(DEK:Database Encryption Key)」によってデータベースを構成するファイルの暗号化が行われ、それぞれのファイルに対して実施されるディスク書き込み時の暗号化、およびディスク読み取り時の暗号化解除の際にDEKが使用される。暗号化方式としては、256ビットの暗号鍵を使用するAES-256が選択されている。

 DEKは組み込みのサーバー証明書によって保護されていて、証明書のメンテナンスとローテーションはサーバーによって管理され、ユーザによる制御は不要である。ただし、データ管理とキー管理を分離する必要がある利用者には、「Azure Key Vault※注」を利用することによってDEKの管理とローテーションの制御が可能になる。

※注:Azure Key Vault=Azure が提供するクラウドベースの外部キー管理システム

 TDE機能は、2017年5月以降に作成されたデータベースではデフォルトで有効化されているが、それより前に作成されたデータベースではデフォルトでは無効化されている。またデータベースの復元やデータベースのコピー、geoレプリケーションで作成されたデータベースも、TDEがデフォルトで無効になっているので注意が必要だ。

★格納中のみならず転送中のデータを暗号化するためのベストプラクティス

●転送中のデータはトランスポート層セキュリティ(TLS)で暗号化
●透過的データベース暗号化によって格納データをバックエンドで自動的に暗号化

前へ 1 2 3 次へ

カテゴリートップへ

この連載の記事