投稿

AWS SQL Server 構築チュートリアル応用：監査設定とパスワードローテーション

RDS for SQL Server の基本構築に加えて、SQL Server Audit、S3 への監査ログ保存、IAM ロールの権限設計、AWS Secrets Manager によるマスターユーザーパスワード管理とローテーションを整理します。

投稿日
Preview Image
投稿者
22 分で読めます
AWS SQL Server 構築チュートリアル応用：監査設定とパスワードローテーション

前回の記事 AWS SQL Server 構築チュートリアル：作成から接続までの実践手順 では、RDS for SQL Server の基本構築を一通り整理しました。DB サブネットグループ、DB パラメータグループ、オプショングループ、S3、IAM、バックアップと復元、接続テストまでを扱いました。

ただし、データベースを本番環境に近い位置へ持っていくなら、「接続できる、バックアップできる、監視できる」だけでは通常まだ足りません。

本番環境では、さらに次の 2 つが重要になります。

  • 誰が、いつ、どのようなデータベース操作を行ったのかを、追跡可能な監査レコードとして残せるか。
  • データベースパスワードが手動保存、手動更新のままなのか、それとも管理可能なローテーションプロセスに入っているか。

この記事では、前回の RDS for SQL Server 構成を前提に、よく使う応用設定として SQL Server Audit とマスターユーザーパスワードのローテーションを追加します。

監査設定

RDS for SQL Server は SQL Server Audit と連携し、監査ファイルを指定した S3 バケットへ出力できます。概念としては、次の 2 つのレイヤーに分かれます。

レイヤー設定すること
AWS RDS レイヤーオプショングループに SQLSERVER_AUDIT を追加し、IAM ロール、S3 バケット、圧縮、保持時間を設定する
SQL Server レイヤーSQL Server 内でサーバー監査、サーバー監査仕様、またはデータベース監査仕様を作成する

つまり、オプショングループは RDS for SQL Server が監査ファイルを S3 に渡せるようにするための設定です。実際にどのイベントを監査するかは、SQL Server 側で監査仕様を作成して決めます。

S3 バケットを作成する

前回作成した S3 バケット markmew-rds-sql-server-backup-restore は、バックアップと復元で使う .bak ファイルを保存するためのものです。技術的には同じバケットを使うこともできますが、本番環境ではバックアップファイルと監査レコードを分けることをおすすめします。

理由は単純です。バックアップと監査では、ライフサイクル、権限境界、保持期間、参照する人が異なることが多いからです。バックアップファイルは DBA や復元フローで使われます。一方、監査レコードはセキュリティ、監査、コンプライアンスの証跡に近いため、より厳格な読み取り権限と保持ポリシーが必要です。

Create S3 audit bucket

ここでは別のバケットを使います。

1

markmew-rds-sql-server-audit

同じバケット内に複数の RDS 監査データを保存する場合でも、少なくともプレフィックスで分けることをおすすめします。

1

sqlserver-audit/

IAM ポリシーを作成する

IAM ロールを作成する前に、先に IAM ポリシーを作成します。こうしておくと、ロール作成時に直接検索してアタッチでき、後から権限を追加しに戻る必要がありません。

IAM Policy

SQL Server Audit の S3 権限では、少なくとも RDS がバケットを確認し、バケット情報を取得し、指定した場所へ監査ファイルを書き込める必要があります。次はデモ用のポリシーです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketACL",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::markmew-rds-sql-server-audit"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:ListMultipartUploadParts",
        "s3:AbortMultipartUpload"
      ],
      "Resource": "arn:aws:s3:::markmew-rds-sql-server-audit/*"
    }
  ]
}

IAM Policy review and create

本番環境でプレフィックスが決まっている場合は、オブジェクト権限をそのプレフィックスに絞ることをおすすめします。たとえば arn:aws:s3:::markmew-rds-sql-server-audit/sqlserver-audit/* のようにします。監査ログでは、通常 RDS がバケット全体へ書き込める必要はありません。

IAM ロールを作成する

次に、RDS が引き受けられる IAM ロールを作成します。このロールは SQL Server Audit が S3 へ書き込むための権限を提供するため、信頼関係では少なくとも rds.amazonaws.com の利用を許可します。

IAM Role

先ほど IAM ポリシーを作成していれば、ここで検索してアタッチできます。

IAM Role attached policy

信頼関係では、まず rds.amazonaws.com を信頼されたエンティティとして指定できます。

IAM Role review and create

デモ環境では、次のようなシンプルな信頼ポリシーから始められます。

1
2
3
4
5
6
7
8
9
10
11
12

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rds.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

本番環境でより厳密にする場合は、aws:SourceAccount と aws:SourceArn を追加し、指定したアカウント、DB インスタンス、オプショングループだけがこのロールを使用できるようにします。前回の記事では、ネイティブバックアップおよび復元用 IAM ロールでこの書き方を示しました。監査用途でも同じ考え方を使えます。

オプショングループに SQLSERVER_AUDIT を追加する

次に、SQL Server が使っているオプショングループへ戻ります。この手順は前回 SQLSERVER_BACKUP_RESTORE を追加したときと似ていますが、今回は SQLSERVER_AUDIT を追加します。

オプションを追加するときは、主に次の項目を設定します。

設定説明
IAM_ROLE_ARNRDS が S3 に書き込むための IAM ロール ARN
S3_BUCKET_ARN監査レコードの送信先となる S3 バケットまたはプレフィックス ARN
ENABLE_COMPRESSION監査ファイルを圧縮するかどうか。デフォルトで有効
RETENTION_TIME監査ファイルを DB インスタンス上に保持する時間。単位は時間で、最大 840 時間

RDS audit option group

設定後、オプショングループには SQLSERVER_BACKUP_RESTORE と SQLSERVER_AUDIT の 2 つのオプションが表示されます。

RDS option group with two options

SQLSERVER_AUDIT の追加に DB インスタンスの再起動は不要です。オプショングループの状態が有効になれば、SQL Server 内で監査を作成し、RDS が完了した監査ログを S3 へアップロードできるようになります。

SQL Server で監査を作成する

オプショングループが有効になったら、SQL Server にログインして監査と監査仕様を作成します。RDS for SQL Server は SQL Server のネイティブな Audit 機能を使いますが、ファイル出力先には RDS 固有の制約があります。

サーバー監査を作成するときは、次に注意してください。

  • FILEPATH には D:\rdsdbdata\SQLAudit を使用する。
  • MAXSIZE は 2 MB から 50 MB の間に設定する。
  • 監査、サーバー監査仕様、データベース監査仕様の名前を RDS_ で始めない。
  • MAX_ROLLOVER_FILES または MAX_FILES を設定しない。
  • audit record の書き込み失敗時に DB インスタンスをシャットダウンする設定にしない。

次は、ログイン失敗イベントを記録する簡単な例です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

USE master;
GO

CREATE SERVER AUDIT [audit_failed_login]
TO FILE (
  FILEPATH = N'D:\rdsdbdata\SQLAudit',
  MAXSIZE = 10 MB
)
WITH (
  QUEUE_DELAY = 1000,
  ON_FAILURE = CONTINUE
);
GO

CREATE SERVER AUDIT SPECIFICATION [audit_failed_login_spec]
FOR SERVER AUDIT [audit_failed_login]
ADD (FAILED_LOGIN_GROUP)
WITH (STATE = ON);
GO

ALTER SERVER AUDIT [audit_failed_login]
WITH (STATE = ON);
GO

これはあくまでデモです。本番環境でどのアクショングループを監査するかは、会社のセキュリティ要件、データの機密性、システムリスクに応じて設計してください。「監査を有効化している」と言うためだけにすべてのイベントを有効化すると、次はストレージ量、分析、アラートノイズの問題になります。

マルチ AZ の注意点

RDS for SQL Server でマルチ AZ を使う場合、SQL Server Audit がオブジェクトごとにどのように動作するかに注意が必要です。

データベース監査仕様はすべてのノードにレプリケートされますが、サーバー監査とサーバー監査仕様はセカンダリノードに自動的にはレプリケートされません。フェイルオーバー後もサーバーレベル監査を継続して取得したい場合は、セカンダリへフェイルオーバーした後、同じ名前と GUID で対応するサーバー監査またはサーバー監査仕様を作成する必要があります。

そのため、監査設定は「オプショングループが有効かどうか」だけで終わらせないほうがよいです。本番環境では、フェイルオーバー後の監査状態も運用訓練に含めることをおすすめします。

パスワードローテーション

データベースパスワードでよくある悪い兆候は、重要だと全員が理解しているのに、実際にはドキュメント、環境変数、CI/CD 設定、誰かのパスワードマネージャーに置かれていることです。時間が経つほど、どのサービスが止まるか分からないため、誰も変更したくなくなります。

RDS では、まずマスターユーザーパスワードを AWS Secrets Manager の管理下に置けます。DB インスタンスの作成または変更時に、RDS にマスター認証情報を管理させることができます。有効化すると、RDS がパスワードを生成し、Secrets Manager に保存し、ローテーション時にデータベース側のマスターユーザーパスワードも同期します。

データベースの編集画面で、AWS Secrets Manager による管理を選択すると、RDS がシークレットを自動的に管理できるようになります。

RDS Secrets Rotate

Secrets Manager を確認すると、認証情報が自動的に作成され、ローテーションも設定されていることが分かります。

Secrets Manager autorotate credentials

自分でパスワードを管理している場合の注意点

まだ RDS 管理のマスター認証情報を使っておらず、自分でマスターパスワードを管理している場合でも、DB インスタンスを変更してパスワードを変えることはできます。ただし、この方法は手動プロセスへの依存が大きく、次の問題が起きやすいです。

  • パスワード変更後、アプリケーション設定が同期されていない。
  • CI/CD、スケジュールジョブ、運用ツールが古いパスワードを使い続けている。
  • パスワード変更後の接続プールや長時間接続の挙動を確認していない。
  • パスワードは変更したが、変更記録や承認フローが残っていない。

また、RDS for SQL Server でマスターユーザーパスワードを作成または変更する場合、RDS が SQL Server 内部のパスワードポリシーに従って弱いパスワードを必ず拒否してくれるとは限りません。操作が成功したとしても、強力なパスワードを使い、監査とイベント通知も組み合わせてリスクを確認してください。

まとめ

RDS for SQL Server の基本構築は、データベースプラットフォームを立ち上げるところまでです。本番環境に近づけるには、さらに「追跡可能であること」と「ローテーション可能であること」を追加する必要があります。

SQL Server Audit は、事後追跡とコンプライアンス証跡を扱います。誰が何をしたのか、どのイベントを記録するのか、監査ファイルをどこに保存するのか、誰が読み取れるのかを整理します。Secrets Manager とパスワードローテーションは、認証情報のガバナンスを扱います。パスワードをドキュメントや手動作業に散らばらせるのではなく、権限制御、記録、ローテーションが可能なリソースとして扱います。

これらの設定は、データベースを作成する作業ほど分かりやすい達成感はありません。それでも、データベースを安心して本番環境へ進められるかどうかを決める重要な要素です。接続できることは第一歩です。監査でき、ローテーションでき、訓練できてこそ、運用できるデータベースになります。

参考資料

AWS, RDS
Database RDS SQL Server
この投稿は投稿者によって CC BY 4.0 の下でライセンスされています。

トレンドのタグ

AWS EC2 IAM Database SSM EKS K8S AI CICD DevOps