コンテンツにスキップ
Orange Check Docs

保健衛生システムNW設定変更方針

1. 概要

本書は、認知症検診管理システムの EC2（Back）から保健衛生システム（衛生DB）の SQL Server を直接参照する方式を採用する場合のネットワーク設定変更方針を示す。

本方式は、認知症検診管理システムが衛生DBに対して参照クエリを実行する構成である。

基本方針

  • 衛生DBに対して、認知症検診 EC2 から SQL Server の待受ポートへの通信のみを許可する
  • 通信元は認知症検診 EC2 のセキュリティグループID1で制限する
  • 許可ポートは衛生システムの SQL Server が実際に使用しているポートのみとする
  • 認知症検診管理システムから衛生DBへの通信のみを許可し、衛生DBから認知症検診管理システムへの新規接続は許可しない
  • データベースユーザーは参照専用権限とし、参照対象は合意済みのテーブルまたはビューに限定する
  • 接続情報は環境変数、AWS Systems Manager Parameter Store2、AWS Secrets Manager3 などで管理し、ソースコードやドキュメントに実パスワードを記載しない

2. 対象環境

本番環境・テスト環境の両方に対して同一方針で設定変更を行う。

項目本番テスト
認知症検診 EC2認知症検診管理システム（本番）VPC内認知症検診管理システム（検証）VPC内
衛生システム SQL Server衛生システム（本番）VPC内衛生システム（検証）VPC内
VPC関係同一VPC同一VPC

3. AWS設定変更内容

3.1 セキュリティグループ（衛生システム SQL Server側）

衛生システムのSQL Serverインスタンスに関連付けられたセキュリティグループに、以下のインバウンドルール4を追加する。

インバウンドルール追加:

項目設定値
タイプカスタムTCP
プロトコルTCP
ポート範囲1433（SQL Server既定ポート）
ソース認知症検診 EC2のセキュリティグループID
説明認知症検診管理システムからの参照接続
  • 認知症検診 EC2のセキュリティグループIDを指定する
  • 衛生システム側のSQL Serverポートが1433以外の場合は、実際の待受ポート番号に読み替える
  • 既存ルールと重複または広い許可がある場合は、追加ルールだけでなく既存ルールの見直し要否を確認する

3.2 セキュリティグループ（認知症検診 EC2側）

認知症検診 EC2のセキュリティグループのアウトバウンドルール5を確認する。

確認事項:

  • デフォルトのアウトバウンドルール（全トラフィック許可: 0.0.0.0/0）が設定されている場合、追加変更は不要
  • アウトバウンドが制限されている場合は、以下のルールを追加する

アウトバウンドルール追加（必要な場合のみ）:

項目設定値
タイプカスタムTCP
プロトコルTCP
ポート範囲1433
デスティネーション衛生システム SQL ServerのセキュリティグループID
説明衛生DBへの参照接続
  • アウトバウンドが全許可の場合でも、基盤運用方針として最小許可が求められる場合は、衛生DB宛の明示ルールへ切り替える

3.3 ネットワークACL6

デフォルトのネットワークACL（全トラフィック許可）が適用されていれば変更不要。カスタムACLが設定されている場合は、ネットワークACLがステートレスであることを前提に、SQL Server 宛の通信と戻り通信をそれぞれ許可する。

確認事項:

  • 認知症検診 EC2 が属するサブネットのネットワークACL
  • 衛生システム SQL Server が属するサブネットのネットワークACL
  • SQL Server 宛 TCP 1433（または実ポート）
  • クライアント側エフェメラルポートへの戻り通信
  • OSまたは基盤標準で定義されたエフェメラルポート範囲

許可例（SQL Server が TCP 1433 の場合）:

対象ACL方向許可する通信
衛生システム SQL Server 側サブネットインバウンド認知症検診 EC2 側CIDRから TCP 1433
衛生システム SQL Server 側サブネットアウトバウンド認知症検診 EC2 側CIDRへのエフェメラルポート
認知症検診 EC2 側サブネットアウトバウンド衛生システム SQL Server 側CIDRへの TCP 1433
認知症検診 EC2 側サブネットインバウンド衛生システム SQL Server 側CIDRからのエフェメラルポート

実際のポート範囲は、認知症検診 EC2 のOS、SQL Server クライアント、基盤標準に合わせて決定する。

4. SQL Server データベースユーザー設定

衛生システム側のSQL Serverに参照専用ユーザーを作成する。権限は合意済みの参照対象に限定し、dbo スキーマ全体への SELECT 付与は行わない。

-- ログインの作成
CREATE LOGIN ninchisho_reader
  WITH PASSWORD = '（強固なパスワード）',
  CHECK_POLICY = ON,
  CHECK_EXPIRATION = ON;


-- 対象データベースにユーザーを作成
USE [衛生DB名];
CREATE USER ninchisho_reader FOR LOGIN ninchisho_reader;


-- 参照対象をビューまたはテーブル単位に限定してSELECT権限を付与
GRANT SELECT ON OBJECT::dbo.vw_ninchisho_juki_reference TO ninchisho_reader;
-- GRANT SELECT ON OBJECT::dbo.<参照対象テーブル名> TO ninchisho_reader;


-- 必要に応じて、参照対象に対する更新系権限を明示的に拒否
DENY INSERT, UPDATE, DELETE ON OBJECT::dbo.vw_ninchisho_juki_reference TO ninchisho_reader;
  • ユーザー名・パスワードは衛生システム管理者と協議の上で決定する
  • 参照対象は、宛名番号、氏名、生年月日、性別、住所など、要件定義で合意した項目に限定する
  • 参照対象が複数テーブルにまたがる場合は、認知症検診管理システム向けの参照ビューを作成し、ビューにのみ SELECT 権限を付与する
  • パスワードはソースコード、手順書、チケット本文に記載せず、基盤運用で定めた秘密情報管理先に登録する
  • SQL Server 接続時は暗号化を有効化し、証明書検証方式を接続文字列と運用手順に明記する

5. 設定変更手順

5.1 事前確認

  1. DB直接参照方式が関係者合意済みであることを確認する
  2. 関連文書がDB直接参照方式と矛盾していないことを確認する
  3. 衛生システム SQL Serverの接続先、待受ポート、サブネット、セキュリティグループIDを確認する
  4. 認知症検診 EC2のサブネット、セキュリティグループIDを確認する
  5. ネットワークACLを確認する
  6. 参照対象テーブルまたはビュー、参照項目、DBユーザー名、資格情報管理先を確認する

5.2 テスト環境

  1. 衛生システム側 SQL Server に参照専用ログイン・ユーザーを作成する
  2. 参照対象ビューまたはテーブルに SELECT 権限を付与する
  3. 衛生システム側セキュリティグループにインバウンドルールを追加する
  4. 認知症検診 EC2側セキュリティグループにアウトバウンドルールを追加する（必要な場合）
  5. カスタムネットワークACLがある場合は、SQL Server 宛通信と戻り通信を許可する
  6. 認知症検診 EC2からポート疎通を確認する
  7. 参照専用ユーザーで SQL Server 接続を確認する
  8. SELECT が成功し、INSERT/UPDATE/DELETE が拒否されることを確認する
  9. アプリケーションから接続・クエリ実行を確認する

5.3 本番環境

テスト環境で問題がないことを確認した後、本番環境に同一方針で適用する。本番適用時は、変更前のセキュリティグループルール、ネットワークACL、DBログイン・ユーザー状態を記録してから作業する。

6. 疎通確認方法

6.1 ネットワーク疎通確認

認知症検診 EC2からSQL Serverへのネットワーク到達性を確認する。

Terminal window
# ポート疎通確認
nc -zv <衛生SQLServerのプライベートIP> 1433

接続先に DNS 名を利用する場合は、名前解決結果も確認する。

Terminal window
nslookup <衛生SQLServerの接続先DNS名>

6.2 データベース接続確認

参照専用ユーザーで接続し、SELECT操作が可能であること、INSERT/UPDATE/DELETE操作が拒否されることを確認する。

確認観点:

  • 接続文字列で暗号化が有効になっている
  • 証明書検証方式が運用方針と一致している（SQL Server接続時にサーバー証明書を検証するか、自己署名証明書を信頼するかなど、TrustServerCertificate や Encrypt の設定が基盤運用で定めた方針に沿っていること）
  • 合意済みの参照対象のみ SELECT できる
  • 合意外のテーブル、INSERT、UPDATE、DELETE、EXECUTE が拒否される
  • アプリケーションログに資格情報や個人情報が出力されない

7. ロールバック手順

設定変更後に問題が発生した場合は、以下の手順でロールバックする。

  1. アプリケーション側の衛生DB参照機能を停止または無効化する
  2. 衛生システム側セキュリティグループから追加したインバウンドルールを削除する
  3. 認知症検診 EC2側のアウトバウンドルール（追加した場合）を削除する
  4. 追加したネットワークACLルール（追加した場合）を削除する
  5. SQL Serverの参照専用ユーザーを削除する
  6. SQL Serverの参照専用ログインを削除する
  7. アプリケーション側の接続情報・秘密情報を削除または無効化する
  8. 変更前状態に戻ったことを、疎通不可、ログイン不可、アプリケーション動作の観点で確認する

Footnotes

  1. セキュリティグループとは、AWSのEC2インスタンスやRDSなどのリソースに対する仮想ファイアウォール機能。インバウンド（受信）・アウトバウンド（送信）それぞれについて、許可する通信のプロトコル・ポート・送信元/送信先をルールとして定義する。セキュリティグループIDを送信元や送信先に指定することで、IPアドレスではなくリソース単位でアクセスを制御できる。 ↩

  2. AWS Systems Manager Parameter Storeとは、設定値や接続文字列などのパラメータを一元管理するAWSのサービス。階層構造で整理でき、暗号化（SecureString）にも対応する。アプリケーションからAPIで値を取得するため、設定ファイルやソースコードに秘密情報を埋め込む必要がない。 ↩

  3. AWS Secrets Managerとは、データベースの認証情報やAPIキーなどの秘密情報を安全に保管・取得するAWSのサービス。自動ローテーション機能を備え、パスワードの定期変更を自動化できる。Parameter Storeと比べ、秘密情報の管理に特化した機能（自動ローテーション、クロスアカウント共有など）を提供する。 ↩

  4. インバウンドルールとは、セキュリティグループにおいて外部からリソースへの受信トラフィックを制御するルール。許可するプロトコル・ポート番号・送信元（IPアドレスやセキュリティグループID）を指定し、条件に合致しない通信はすべて拒否される。 ↩

  5. アウトバウンドルールとは、セキュリティグループにおいてリソースから外部への送信トラフィックを制御するルール。デフォルトではすべての送信トラフィックが許可されているが、最小権限の原則に基づき、必要な宛先・ポートのみに制限することもできる。 ↩

  6. ネットワークACL（Access Control List）とは、VPC内のサブネット単位で通信を制御するファイアウォール機能。セキュリティグループがリソース単位・ステートフル（戻り通信を自動許可）であるのに対し、ネットワークACLはサブネット単位・ステートレス（送信・受信それぞれにルールが必要）で動作する。 ↩