MySQL の強化の概要

徹底的なセキュリティ: インターネット全体を簡単にスキャンし、数秒でパスワードを解読できる攻撃者は存在します。パブリック IP ネットワーク経由でアクセス可能なデータベースを残すことも必要な場合もありますが、その場合、データベースの脆弱性は飛躍的に高まります。パブリック IP のリスクを軽減する方法の一つは、データベースへのアクセスを限られた IP アドレスのセットに制限することです。

とはいえ、Virtual Private Cloud（VPC）内でのみアクセスを許可し、踏み台インスタンス内でのみオペレーターの接続を許可するのが優れたソリューションです。Google Cloud では、このソリューションはプライベート IP と呼ばれます。MySQL インスタンスに VPC 内でのみアクセスできる場合、攻撃者はインスタンスへの侵入を試みる前に、まず VPC を侵害する必要があります。

MySQL のすべてのマイナー バージョンにはリリースノートがあり、ほぼ必ずセキュリティ アップデートのセクションが含まれています。インスタンスが数バージョン古い場合、データベースに適用されていないバージョンのセキュリティに関する修正がいくつかあります。

MySQL では、セキュリティ上の問題を徐々に修正するだけでなく、いくつかのまったく新しいセキュリティ機能も定期的に導入されています。たとえば、MySQL 8.0 では、ロール、失敗したログインのトラッキング、ランダムなパスワード生成など、MySQL スキーマとユーザーを強化するための多くの方法が導入されました。

コーヒー ショップで仕事をしていて、クエリを実行したいとします。この場合、ショップの無料 Wi-Fi ネットワークを介して MySQL に接続します。TLS（Transport Layer Security）を使用しなかった場合は、TCP（伝送制御プロトコル、インターネットの主なプロトコルの 1 つ）を介してユーザー名とパスワードを実質的に公にしているのです。MySQL インスタンスに TLS を適用すると、他のユーザーがネットワークをのぞき見しているかどうかを心配せずに、ラテを飲みながら仕事ができます。

SQL インジェクション

多くの場合、攻撃に対して最も脆弱なのはデータベースではなくアプリケーションです。多くのアプリケーションが SQL インジェクション攻撃の被害に遭っています。SQL インジェクションは、アプリケーションが有効な SQL ステートメントだと判断した悪意のある入力を攻撃者が挿入するものです。これらの攻撃に対する最善の保護は、SQL ステートメントの作成時にユーザー入力と SQL ステートメントを連結するのではなく、あらかじめ準備されたステートメントを使用することです。

リポジトリ内のシークレット

開発者が誤ってユーザー名とパスワードをソースコード リポジトリに push したために、無数のデータベースが侵害されました。代わりに、データベース パスワードなど、あらゆる種類の Secret を管理する Google Cloud の Secret Manager などのツールを使用してください。

パスワードのロギング

最後に、ロギング フレームワークのフィルタ ツールを使用して、アプリケーションのログからデータベースのパスワードを除外します。例としては、Log4j Filters や Rails ParameterFilter などがありますが、ほとんどのロギング フレームワークには同等のものがあるはずです。ない場合は、データベースを保護するために、アプリケーション ログのセキュリティを確保する必要があります。

データベース上のすべてのパスワードが十分に複雑であることを確認するために、パスワード検証の使用を検討してください。アプリケーション パスワードは長く複雑なものにし、頻繁にローテーションします。Secret Manager は、複雑で頻繁に変更されるパスワードを記憶する必要がないため特に便利です。

アプリケーションではなく人間がデータベース ユーザーを使用する場合は、NIST の標準に従い、長さを何よりも優先します。パスワードの有効期限や過度に複雑なパスワード要件によって、人々は平文ファイルや付箋に記憶を任せることが多く、これによりルール全体の目的に反することになります。

さらに、アプリケーション以外のユーザーに対して IAM 認証の利用を検討してください。IAM 認証では、接続の確立が Google Cloud の IAM サービスに委任されます。つまり、リスクは IAM ユーザーとデータベース ユーザーではなく、IAM ユーザーのみに軽減されます。

最後に、MySQL のデフォルトのデータベース パスワードは、ソルトではなくハッシュです。つまり、同じパスワードを持つユーザーには同じ認証文字列が使用されるため、脆弱なパスワードをレインボー テーブル攻撃で解明する手間が省けます。次の 2 人の MySQL ユーザーは同じ authentication_string を使用しています。

フラグ default_authentication_plugin を caching_sha2_password に設定することを検討してください。これにより、同じパスワードを使用する 2 人のユーザーは異なるハッシュを持つようになります。次の例では、2 人のユーザーの authentication_string の値が異なります。

アクセスを制限することは、外部からのアクセスを保護するだけでなく、また、内部からのアクセスを定期的に監査することでもあります。

アプリケーションを監査する: 課金テーブル、プロダクト テーブル、お客様テーブルからのみ読み取る場合、それ以外へのアクセス権は本当に必要でしょうか？データベースにルートアクセスを許可したままにしておくと、攻撃者がデータベースに多大な損害を与える可能性があります。そうではなく、インスタンスの要件をすべて検討し、必要な権限を項目別に列挙して、それぞれに対応するデータベース ユーザーを作成してください。攻撃者がこのデータベース ユーザーのいずれかの下でデータベースを侵害した場合、被害の範囲は限定的なものとなります。

ユーザーを監査する: インスタンスの管理者権限を本当に必要としているデータベース ユーザーはどれくらいいるでしょうか？そのうち、まだ組織に所属しているユーザー、アクティブでないプロジェクトに接続しているユーザー、またはユーザー自体が非アクティブなユーザーの数は？アクセス トークンは漏洩する可能性があり、インサイダー脅威はほとんどのシステムで常に懸念の対象とされます。ユーザー数をできるだけ少なくすると、この種の問題からインスタンスを保護するのに役立ちます。

「管理者」を監査する: 「root」や「管理者」のようなユーザーを削除するか、名前を変更します。これらは攻撃者にとって容易な標的であり、存在しない場合、システムの侵害が少しだけ難しくなります。これは隠ぺいによるセキュリティと呼ばれます。これを最前線の防御とすることはできませんが、MySQL データベースに薄いレイヤのセキュリティを追加できます。

健全なデータベース管理には、定期的なデータ バックアップと検証可能なデータ復旧計画が不可欠です。ただし、定期的なバックアップを行っても、前回のバックアップ以降に書き込まれたすべてのデータを失う可能性は依然としてあります。MySQL エコシステムの利点の一つは、任意の時点でデータを復元できるポイントインタイム リカバリ（PITR）です。PITR を有効にするには、Cloud SQL for MySQL インスタンスでバイナリログを有効にします。

上記をすべて実施していれば、対策やセキュリティは万全です。とはいえ、継続的な警戒、つまりデータベースの監査がなくては、セキュリティの設計は完成しません。Cloud SQL for MySQL 監査プラグインを使用すると、侵害発生時の異常な動作を追跡できます。

以上を実施することにより、攻撃者がデータベース侵害への道筋を整えるのが難しくなります。攻撃者は、アプリケーションを侵害して、アプリケーションのデータベース ユーザーが攻撃に対して十分な権限を持っていることを期待するか、VPC を侵害して、既存のユーザー名を見つけ、パスワードを破り、攻撃を実行する十分な権限があることを期待します。その間、MySQL データベース ログまたは監査ログを表示してデータベースに対する通常の動作をモニタリングし、それに応じて対処できます。

これが、安全性を重視した設計です。攻撃者は今後も新たな方法でマシンを悪用するでしょう。そのため、データベースを保護するために、できる限り多くの保護レイヤを備えたシステムを設計することが重要です。