DMS の領域を超えて: SQL Server のログインとユーザーを Cloud SQL に効率的に移行

※この投稿は米国時間 2026 年 9 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

データベースのモダナイゼーションを計画したとしましょう。Google Cloud の Database Migration Service（DMS）を設定し、レプリケーションを構成して、オンプレミスまたはクラウド システムからフルマネージドの Cloud SQL for SQL Server インスタンスにアプリケーション データベースを正常に同期しました。

そしてレプリケーションが完了し、データが最新の状態になり、カットオーバーの準備が整いました。しかし、移行したばかりのデータベースにアプリケーションを接続しようとすると、次のメッセージが表示され、壁にぶつかります。

Msg 18456, Level 14, State 1, Line 1: Login failed for user 'app_user.

原因は単純です。SQL Server のログインが、データベースと一緒に移行されなかったからです。この投稿では、このギャップが存在する理由、これが組織のセキュリティ ポスチャーの保護につながる理由、そして長年の実績がある標準的な SQL Server ツールを使用して簡単にこのギャップを埋める方法をご説明します。

DMS でログインが移行されない理由: セキュリティとコンプライアンス

Database Migration Service（DMS）は、データベース レベルのスキーマとトランザクション データを非常に効率的に複製しますが、システム master データベースやサーバーのログインと権限などのインスタンス レベルのオブジェクトは移行しません。これは、意図的な動作です。

機能が欠けているように感じられるかもしれませんが、実際には、次の 3 つの基本方針に基づく慎重な設計なのです。

1. セキュリティの分離と権限の境界: 移行元の環境と移行先の Cloud SQL 環境は、異なるセキュリティ パラダイムで運用されています。マスター システム データベースを直接複製すると、不正な権限昇格につながる可能性があります。たとえば、sysadmin 権限を持つオンプレミスのログインに、フルマネージドの Google Cloud データベースへの無制限の sysadmin アクセス権を付与すべきではありません。クラウド プロバイダが物理的なバックアップ、パッチ適用、セキュリティを管理する場合、適切な運用を確保するために、基盤となるオペレーティング システムへのアクセスを制限する必要があります。

2. コンプライアンスと監査ガバナンス: 暗号化されたパスワード ハッシュとサーバーレベルのセキュリティ認証情報を、管理者の明示的な監視なしに自動的に移行した場合、PCI-DSS や SOC 2 などの企業のコンプライアンス フレームワークに違反してしまうことが珍しくありません。セキュリティ オブジェクトの移行を管理者が主導する慎重なステップとして維持することで、組織は承認された ID のみがクラウド ランディング ゾーンにプロビジョニングされることを保証できます。

3. ID のモダナイゼーションの必要性: クラウドへの移行は、古くなった認証情報を更新および削除する絶好の機会です。オンプレミス インスタンスには、使用されなくなった以前の SQL ログインが含まれていることがよくあります。深く考えずにそれらをクラウド マネージド サービスに複製することは、セキュリティのアンチパターンです。さらに、Cloud SQL への移行が、以前の SQL 認証から、顧客管理の Active Directory（CMAD）などのクラウドネイティブな最新の ID ソリューションへの移行を促進するきっかけとなることがよくあります。

ログインとユーザーの違い: SID 接続

ログインを正常に移行するために、SQL Server がセキュリティを管理する方法を簡単に復習しておきましょう。SQL Server では、ID が次の 2 つのレイヤに分かれています。

• ログイン（サーバーレベル）: master データベースに保存されます。ログインは、SQL Server インスタンスへのクライアント接続を認証します。

• ユーザー（データベース レベル）: 個々のユーザー データベース内に保存されます。ユーザーは、その特定のデータベース内で接続が実行できるアクションを承認します。

サーバー ログインとデータベース ユーザーを橋渡しするのは、一意のセキュリティ識別子（SID）です。

データベースをバックアップして復元する（または DMS を使用して複製する）と、データベース レベルの「ユーザー」（および対応する SID）がデータベース ファイル内に移行されます。ただし、対応するサーバーレベルの「ログイン」が移行先の master データベースに存在しない場合、または存在しても SID が異なる場合、マッピングは解除されます。これにより、データベース アクセス権限はあるものの、サーバーレベルで認証できない「孤立したユーザー」が生じます。

推奨ソリューション: sp_help_revlogin を使用してログインを複製する

すべてのログインを手動で再作成し、パスワード ハッシュの見当を付けようとする代わりに、Microsoft が従来より提供しているスクリプト sp_help_revlogin を使用するとよいでしょう。

このスクリプトは、移行元インスタンスのすべての SQL Server 認証ログイン用 CREATE LOGIN ステートメントを含む T-SQL クエリを生成します。このステートメントは、元の暗号化されたパスワード ハッシュと正確なセキュリティ識別子（SID）を備えています。

ステップ 1: 移行元インスタンスでヘルパー プロシージャを作成する

SQL Server Management Studio（SSMS）を使用して、移行元の SQL Server インスタンスに接続します。Microsoft の公式スクリプトをコピーして実行し、移行元の master データベースに 2 つの必須ストアド プロシージャ（sp_hexadecimal と sp_help_revlogin）を作成します。

ステップ 2: 移行スクリプトを生成する

プロシージャが作成されたら、SSMS のクエリ ウィンドウで次のステートメントを実行します。出力を正確にコピーするには、出力設定を [Results to Text] に切り替えてください（Ctrl+T）。

出力には、次のような自動生成された T-SQL ステートメントが含まれます。

HASHED パスワード オプションと元の SID を使用してログインをスクリプト化することで、SQL Server で元のパスワードと安全なリンクをそのまま維持してログインを安全に再作成できます。

ステップ 3: スクリプトを Cloud SQL に適用する

生成されたスクリプトをコピーし、移行先の Cloud SQL for SQL Server インスタンスに接続して、クエリを実行します。ログインは、正しいパスワードでクラウドに即座に作成されます。

sp_help_revlogin によって生成されたスクリプトを実行することで、正確なセキュリティ識別子（SID）とパスワード ハッシュをそのまま維持した状態で、移行先の Cloud SQL インスタンスにログインを複製できます。以下に示すように、これにより、データベース レベルのユーザーがデータベースの移行時にサーバーレベルのログインに自動的にマッピングされるため、「孤立したユーザー」を完全に回避できます。

注: sp_help_revlogin は、Microsoft が作成、管理しているストアド プロシージャです。必ず最新バージョンをダウンロードし、ドキュメントをお読みください。

孤立したユーザーのトラブルシューティング

sp_help_revlogin を実行する前に、移行先の Cloud SQL インスタンスにログインを手動で作成していた場合、SID が一致せず、ユーザーが「孤立」する可能性があります。

孤立したユーザー（app_user など）が見つかった場合は、次の 1 つのコマンドで簡単に、新しく作成したサーバー ログインに再マッピングできます。

このコマンドにより、データベース ユーザーとサーバー ログインが SID を介してすぐに再結合され、アプリケーションの接続が完全に復元されます。

セキュリティをさらに強化

sp_help_revlogin を使用した SQL ログインの移行は、リフト＆シフト移行の最も簡単な方法ですが、クラウド移行を利用した認証のモダナイズもご検討いただけます。Cloud SQL for SQL Server は、顧客管理の Active Directory（CMAD）との堅牢な統合をサポートしています。移行先インスタンスを Active Directory と統合することで、従来の SQL ログインを廃止し、一元化されたエンタープライズ グレードの Kerberos 認証に移行できます。

まとめ

データベースの移行は、単なるデータ行の移動ではありません。アプリケーションのセキュリティ、コンプライアンス、運用性を初日から確保することが重要です。Google Cloud の DMS によってデータ レプリケーションの煩雑な処理を行う一方、シームレスなカットオーバーを保証する簡単な 3 ステップのプロセスでログインを移行できます。

移行戦略の最適化について詳しくは、Cloud SQL for SQL Server 移行ガイドをご覧ください。また、Database Migration Service を使用して Google Cloud への移行を効率化する方法もご確認ください。

- SQL Server ブラックベルト、Assaf Fraenkel

- シニア プロダクト マネージャー、Adi Shtatfeld