接続する Azure Database for MySQL Excel、Google Sheets、AI、RESTへ

ここでTLSはホスト名ではなくチェックボックスに従います。

ここはAzure PostgreSQLのページをそのままコピーするのが間違っている唯一の箇所なので、はっきりと述べておく価値がある。

• SSLの使用はデフォルトで有効になっており、有効になっている間は接続が暗号化されます。 エージェントはMySQLに必須のTLSセッションを要求します。
• これをオフにすると、エージェントは暗号化されていない接続を試みます。MySQL パスにはホスト名に基づいてそれを上書きする設定はなく、まさにこの点が、このカードが Azure PostgreSQL と異なる点です。
• 理由は見落としではなく構造的なものです。エージェントはTLSを強制するホスト型Postgresホスト名のテーブルを保持していますが、MySQLにはそれに相当する機能がありません。チェックボックスがその仕組みのすべてです。
• 暗号化は証明書の検証ではありません。エージェントはTLSを要求しますが、サーバーの証明書チェーンを検証しないため、これは通信内容の証明ではなく、傍受に対する保護策として捉えてください。

柔軟なサーバーとユーザー名の罠

AzureはMySQLを2つの形式で提供しており、ユーザー名の表示形式について意見が分かれている。このカードはどちらか一方の立場を示している。

• このカードはフレキシブルサーバー向けに設計されています。ポートはデフォルトで3306に設定されており、サーバー名は.mysql.database.azure.comで終わります。
• フレキシブルサーバーでは、シンプルなユーザー名を使用します。廃止されたシングルサーバーサービスでは、user@servername の形式が使われていましたが、この形式を貼り付けると、Azure が認証エラーとして拒否するのを防ぐため、末尾の拡張子を削除するように指示されます。
• そこがエラーを捕捉するのに最適な場所です。@servername によるログインは、最終段階で一般的な認証エラーとして失敗し、実際には間違っていないパスワードのリセットをユーザーに促します。
• 先頭または末尾に空白文字が含まれるパスワードもエラーとして検出されます。これはクリップボードの痕跡であり、通常の認証エラーと同様に失敗します。

プライベートエンドポイントはエージェントに適しています

エージェントは発信するだけで受信を待たないため、データベースサーバーを公開する通常の理由は当てはまりません。

• エージェントを同じVNet内のVMに配置し、プライベートエンドポイントに向けます。パブリックアクセスは無効のままで構いません。
• 受信ファイアウォールルールを追加する必要も、IPアドレスの許可リストを管理する必要も、お客様のネットワークと弊社ネットワーク間のVPN接続も必要ありません。エージェントが外部への接続を確立します。
• 認証にはユーザー名とパスワードが必要です。Microsoft Entra IDはこのコネクタに組み込まれていないため、公開したい情報を読み取るためのスコープを設定したMySQLログインを使用してください。
• 読み取り専用ユーザーであれば、2分程度の時間をかける価値はあります。クエリ ストリームは書き込みを行いませんが、それを確実に保証する最も安全な方法はデータベースを使用することです。

-- 通常の MySQL、読み取り専用、TLS 経由 SELECT c.name, COUNT(o.id) AS orders, SUM(o.amount) AS revenue FROM customers AS c JOIN orders AS o ON o.customer_id = c.id WHERE o.placed_at >= NOW() - INTERVAL 30 DAY GROUP BY c.name ORDER BY revenue DESC;