データベースとサーバーを保護する

9 分

データベースの認証と認可は、従来からオープンソースのデータベースをセキュリティで保護する方法として使用されてきました。そのデータベースを Azure でホストすることで、その保護を強化できる可能性があります。

あなたは Adventureworks のデータベース開発者として、会社の Azure Database for PostgreSQL の保護を強化したいと考えています。

このユニットでは、オンプレミスの PostgreSQL データベースを Azure に移行したことにより、さらにどのような保護が可能であるかを確認できます。

データを保護する

PostgreSQL と MySQL には、データベースへのアクセスが許可されているユーザーとそれらのデータベース内のアイテムに対する権限を制御する、独自の認証および認可メカニズムがあります。移行前とほぼ同じ方法で、ユーザーと権限を引き続き管理する必要があります。 PgAdmin や MySQL ワークベンチなどの管理ツールを使用して、Azure でホストされているサーバーに接続できることを思い出してください。

ただし、Azure ではサーバーに対する追加の保護が提供されます。この保護は、次の 3 つのレベルで動作します。

サーバーへのアクセスを制御し、不明なソースまたは信頼されていないソースからのトラフィックをフィルター処理します。
トラフィックを保護することで、クライアントからサーバーに転送されたり、再び転送して戻されたりするときに、改ざんや傍受を行うことができないようにします。
サーバー自体を外部の一般的な脅威から保護します。

以降のセクションでは、これらの項目について詳しく説明します。

ファイアウォール規則を使用してトラフィックをフィルター処理する

Azure Database for MySQL または PostgreSQL は、Microsoft によって管理されるファイアウォール内で実行されます。既定では、何もこのファイアウォールを通過することはできません。前のモジュールで説明したように、指定された IP アドレスのブロックからのトラフィックを有効にするファイアウォール規則を追加します。トラフィックを頻繁に送信することが許可されている IP アドレスを積極的に確認し、不要になったクライアントの IP アドレスを削除することをお勧めします。

データベースを使用する必要がある他の Azure サービスを実行している場合は、これらのサービスに対してファイアウォールを開く必要があります。 Azure portal の Azure Database for MySQL または PostgreSQL サービスの [接続のセキュリティ] ページで、[Azure サービスへのアクセスを許可] アクション設定を [オン] にします。

Image highlighting the Allow access to Azure services action setting in the firewall configuration for Azure Database for MySQL or PostgreSQL

Note

ファイアウォールに対して行った変更がアクティブになるまでに、最大で 5 分かかることがあります。

場合によっては、すべての Azure サービスに対してサーバーを開くことが過剰であることがあります。 Azure Database for MySQL または PostgreSQL の General Purpose または Memory Optimized バージョンを実行している場合は、Azure Virtual Network の規則を使用して、仮想ネットワークレベルでトラフィックをフィルター処理します。仮想ネットワーク規則を使用すると、独自の仮想ネットワークから発信されたトラフィックに対してサーバーへのアクセスを許可することができます。他のネットワークからのトラフィックはブロックされます。

Image showing the virtual network rules for Azure Database for MySQL or PostgreSQL

ファイアウォールのメンテナンスタスクをスクリプト化する必要がある場合は、Azure CLI を使用します。次の例では、ファイアウォール規則を追加、削除、表示するために、Azure Database for MySQL に対して操作を実行する az mysql コマンドを使用しています。 PostgreSQL コマンドを実行している場合は、代わりに対応する az postgres コマンドを使用します。パラメーターは同じです。

13.83.152.0 から 13.83.152.15 までの範囲のクライアントへのアクセスを許可する

az mysql server firewall-rule create \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name] \
    --name FirewallRule1 \
    --start-ip-address 13.83.152.0 \
    --end-ip-address 13.83.152.15

すべてのファイアウォール規則を表示する

az mysql server firewall-rule list \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name]

FirewallRule1 の詳細を表示する

az mysql server firewall-rule show \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name] \
    --name FirewallRule1

FirewallRule1 を削除する。この規則のアドレス範囲内のクライアントはアクセスを拒否される

az mysql server firewall-rule delete \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name] \
    --name FirewallRule1

Azure サービスへのアクセスを有効にするには、start-ip-address と end-ip-address の値に 0.0.0.0 を使用してファイアウォール規則を作成します。

仮想ネットワーク規則を作成および管理するには、同様に az msysql server vnet-rule コマンドを使用します。

SSL を使用してトラフィックを保護する

Azure Database for MySQL または PostgreSQL の SSL 保護は、既定で有効になっています。 SSL を無効にしたり、再度有効にしたりするには、Azure portal で Azure Database for MySQL または PostgreSQL サービスの [接続のセキュリティ] ページの [SSL 接続を強制する] 設定を使用します。

Image highlighting the Enforce SSL connection setting on the Connection security page for Azure Database for MySQL or PostgreSQL

Azure Advanced Threat Protection を使用してサーバーを保護する

Advanced Threat Protection は、Azure によって提供される追加のセキュリティ層です。 Advanced Threat Protection では、サーバーへのアクセスを監視し、異常な動作や悪意のある可能性のある動作のパターンを見つけます。このような動作が検出された場合に指定された電子メールアドレスにアラートが送信されるように設定します。

検出される異常なアクティビティのパターンには次のものがあります。

予期しない場所や通常とは異なる場所からのアクセス。
通常とは異なる Azure データセンターからのアクセス。
危険な可能性があるアプリケーションからのアクセス (認識されている攻撃ツールなど)。
短時間で多数のログインが連続して失敗し、ブルートフォース攻撃の可能性を示している。

Advanced Threat Protection を有効にするには、Azure portal でサービスの [Advanced Threat protection] ページを使用します。

Image showing the Advanced Threat Protection page for Azure Database for MySQL or PostgreSQL

サーバーのバックアップと復元

Azure Database for MySQL または PostgreSQL サービスでは、次のスケジュールに従ってサーバーが自動的にバックアップされます。

完全バックアップは毎週取得され、サーバーが作成されるとすぐに最初の完全バックアップが行われます。
差分バックアップは 1 日に 2 回取得されます。
トランザクションログのバックアップは、5 分ごとに取得されます。

サーバー全体がバックアップされます。個々のデータベースをバックアップすることはできません。また、バックアップを手動で実施することもできません。

バックアップのオプションを設定する

バックアップファイルが保持されている任意の時点に復元するには、これらのバックアップを使用します。既定では、バックアップは 7 日間保持されますが、最大 35 日間保持できます。バックアップの保存方法も指定します。ローカル冗長バックアップはサーバーと同じリージョンに保持され、geo 冗長バックアップは他のリージョンのデータセンターにコピーされます。 geo 冗長オプションは、General Purpose と Memory Optimized 価格レベルのサーバーでのみ利用できます。バックアップオプションは、Azure portal のサーバーの [価格レベル] ページで設定します。

Image showing the backup configuration section of the pricing tiers page for Azure Database for MySQL or PostgreSQL

サーバーの復元

Azure Database for MySQL または PostgreSQL では、ポイントインタイムと geo リストアの 2 種類のサーバー復元操作がサポートされます。どちらの場合も、復元アクションによって新しいサーバーが作成されます。元のサーバーは使用可能な状態のままになります。アプリケーションで復元されたデータを使用する場合は、新しいサーバーを使用するようにアプリケーションを再構成する必要があります。また、新しいサーバーのファイアウォールを開いて、クライアントとサービスが接続可能になるようにする必要があります。

重要

削除されたサーバーを復元することはできません。サーバーを削除すると、そのサーバーに関連付けられているバックアップも削除されます。

ポイントインタイムリストア

ポイントインタイムリストアでは、元のサーバーのバックアップを使用して新しいサーバーを作成し、サーバーを指定した時間にロールフォワードします。復元操作を開始するには、Azure portal のサーバーの [概要] ページのツールバーにある [復元] を使用します。新しいサーバーの名前と特定の時点を入力するように求められます。

Image showing the point-in-time restore page for Azure Database for MySQL or PostgreSQL

コマンドラインから復元操作を実行する場合、Azure CLI では az mysql/postgres server restore コマンドがサポートされます。次に例を示します。

az mysql server restore \
    --resource-group [resource group name] \
    --name [new Azure Database for MySQL server name] \
    --source-server [original Azure Database for MySQL server name] \
    --restore-point-in-time "2019-10-23T02:10:00+08:00"

geo リストア

geo リストアでは、geo 冗長ストレージに保持されているバックアップを使用して、サーバーを完全に復元します。 Azure portal を使用して新しいサーバーを作成するときに、geo 冗長バックアップをデータソースとして指定します。新しいサーバーが作成されるときに、このバックアップのデータベースが移入されます。

Image showing the server details section when creating an Azure Database for MySQL or PostgreSQL server

Azure CLI には、コマンドラインから geo リストアを実行するための az mysql/postgres server georestore コマンドが用意されています。

geo 冗長バックアップを別のリージョンにレプリケートするには、最大 1 時間かかることがあります。このため、別のリージョンから geo リストアを実行する必要がある場合に、最大 1 時間分のデータが失われる可能性があります。