MySQL データベースをオンプレミス環境から Azure Database for MySQL に移行する場合は、堅牢なセキュリティを確保することが最も重要です。 この記事では、移行中にデータを保護するための重要なセキュリティ上の考慮事項とベスト プラクティスについて詳しく説明します。 高度な脅威に対する保護、暗号化、アクセス制御などの Azure の包括的なセキュリティ機能を使用すると、潜在的な脆弱性や脅威からデータベースを保護できます。 このガイドでは、データ暗号化、ネットワーク セキュリティ、コンプライアンスなどの重要な側面に対処し、セキュリティで保護された移行戦略を実装するために必要な分析情報を提供します。 データ保護を強化すること、規制要件を満たすこと、またはデータベースの整合性を確保することを目的とする場合でも、この記事を読むと、安全かつ確実な移行を実現するための知識が得られます。
前提条件
オンプレミスの MySQL を Azure Database for MySQL に移行する: 事業継続とディザスター リカバリー (BCDR)
概要
クラウドベースのサービスへの移行は、インターネット全体が常にそれにアクセスできることは意味しません。 Azure では、不正ユーザーや悪意のあるプログラムからデータ ワークロードを継続的に保護できるクラス最高のセキュリティを提供します。
認証
Azure Database for MySQL は、MySQL ユーザー接続のための基本的な認証メカニズムをサポートしていますが、Microsoft Entra ID との統合もサポートしています。 このセキュリティ統合は、MySQL ログイン プロセス中にパスワードのような機能を果たすトークンを発行することで機能します。 Active Directory 統合の構成は非常に簡単であり、ユーザーだけでなく、Microsoft Entra グループもサポートしています。
この緊密な統合により、管理者とアプリケーションは、Azure Identity Protection の強化されたセキュリティ機能を利用して、ID 関連の問題をはっきりと明るみに出すことができます。
注意
このセキュリティ機能は、MySQL 5.7 以降でサポートされています。 clear-text オプションが指定されていれば、ほとんどのアプリケーション ドライバーがサポートされます。
脅威の防止
ユーザーまたはアプリケーションの資格情報が漏洩すると、ログインの試行失敗に関する情報がログに表示されなくなる可能性があります。 資格情報が漏洩すると、不正ユーザーがデータにアクセスしてダウンロードできるようになる可能性があります。 Azure Threat Protection では、ログインの異常 (通常とは異なる場所、まれなユーザー、ブルート フォース攻撃など) をはじめとする疑わしいアクティビティを監視できます。 管理者は、look に何か問題が発生した場合に通知を受け取ることができます。
監査ログ
MySQL には、堅牢な監査ログ機能が組み込まれています。 既定では、Azure Database for MySQL でこの監査ログ機能が無効になっています。 サーバー レベルのログは、audit\_log\_enabled サーバー パラメーターを変更することで有効にすることができます。 有効にしたら、診断ログを有効にすることで、Azure Monitor と Log Analytics からログにアクセスできます。
ユーザー接続関連のイベントを照会するには、次の KQL クエリを実行します。
AzureDiagnostics
| where ResourceProvider =="MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlAuditLogs' and event\_class\_s == "connection\_log"
| project TimeGenerated, LogicalServerName\_s, event\_class\_s, event\_subclass\_s
, event\_time\_t, user\_s , ip\_s , sql\_text\_s
| order by TimeGenerated asc
暗号化
MySQL インスタンス内のデータは、既定では保存時に暗号化されます。 また、承認されていない関係者へのデータ漏洩の可能性を防ぐために、自動バックアップも暗号化されます。 通常、この暗号化は、インスタンスの作成時に作成されるキーを使用して実行されます。 この既定の暗号化キーに加えて、管理者は Bring Your Own Key (BYOK) を使用することもできます。
カスタマー マネージド キー戦略を使用する場合、キー ライフサイクル管理に関する責任を理解しておくことが重要です。 カスタマー キーは Azure Key Vault に格納され、ポリシーを介してアクセスされます。 キー管理に関するすべての推奨事項に従うことが重要です。暗号化キーが失われると、データ アクセスが失われます。
カスタマー マネージド キーに加えて、サービスレベルのキーを使用して二重暗号化を追加します。 この機能を実装すると、保存データを高度に暗号化できますが、暗号化のパフォーマンスが低下します。 テストを実施することをお勧めします。
SSL/TLS を使用すると、転送中のデータを暗号化できます。 前に説明したように、この変更をサポートするためにはアプリケーションを変更し、適切な TLS 検証設定を構成することが必要になる場合があります。
ファイアウォール
ユーザーが設定され、データが保存時に暗号化されたら、移行チームはネットワーク データ フローを確認する必要があります。 Azure Database for MySQL には、許可されているユーザー、アプリケーション、デバイスだけにアクセスを制限してネットワーク レイヤーをセキュリティで保護するメカニズムがいくつか用意されています。
MySQL インスタンスを保護するための防御の最前線は、ファイアウォール規則の実装です。 内部または外部 IP を介してインスタンスにアクセスする場合、IP アドレスを有効な場所だけに制限できます。 MySQL インスタンスが内部アプリケーションにのみサービスを提供することになっている場合は、パブリック アクセスを制限します。
アプリケーションを MySQL ワークロードと共に Azure に移行する場合、複数の仮想ネットワークがハブ アンド スポーク パターンで設定されており、仮想ネットワーク ピアリングの構成が必要になる可能性があります。
プライベート リンク
Azure Database for MySQL へのアクセスを内部 Azure リソースに制限するには、Private Link を有効にします。 Private Link を使用すると、MySQL インスタンスに、パブリック IP アドレスではなくプライベート IP を割り当てることができます。
注意
このガイドでは取り上げていませんが、考慮する必要がある、Azure ネットワークに関する基本的な考慮事項がほかにも多数あります。
すべての Azure リソースで実践できる可能性のある一連のセキュリティ ベースライン タスクを確認します。 参照リンクに記載されている項目は、必ずしもすべてが特定のデータ ワークロードまたは Azure リソースに適用されるわけではありません。
セキュリティ チェックリスト
可能な場合は、Microsoft Entra 認証を使用してください。
Advanced Thread Protection を有効にします。
すべての監査機能を有効にします。
Bring-Your-Own-Key (BYOK) 戦略を検討します。
ファイアウォール規則を実装します。
インターネットを経由しないワークロードには、プライベート エンドポイントを使用します。