Amazon RDS データベースインスタンスでのカスタム管理者名の設定について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。

今回は、Amazon RDS (Relational Database Service) のデータベースインスタンスがデフォルトの管理ユーザーネームを使用している状態について、そのリスクと対策を解説します。

リスク

Amazon RDSは、リレーショナルデータベースをAWSクラウドで簡単にセットアップ、運用、スケールできるフルマネージドサービスです。MySQL、PostgreSQL、SQL Server、Oracle、MariaDB、Amazon Auroraなど多様なデータベースエンジンをサポートしています。

多くのデータベースエンジンには、デフォルトの管理ユーザーネームが存在します。例えば、PostgreSQLではpostgres、MySQLではroot、SQL Serverではsaなどが一般的です。Amazon RDSでデータベースインスタンスを作成する際、これらのデフォルトユーザーネームをそのまま使用するオプションがあります。しかし、このデフォルト設定のまま運用している場合、以下のような重大なセキュリティリスクが発生します。

  • ブルートフォース攻撃の容易化: 攻撃者は、デフォルトの管理ユーザーネームが広く知られていることを利用し、辞書攻撃やブルートフォース攻撃を試みる際に、ユーザーネームを特定する手間を省くことができます。これにより、認証情報の特定が容易になり、データベースへの不正アクセスのリスクが大幅に高まります。
  • 認証情報漏洩時のリスク増大: もし他のシステムやサービスからパスワードが漏洩した場合、デフォルトユーザーネームと組み合わせることで、簡単にデータベースの管理権限を奪われる可能性があります。これにより、データの改ざん、削除、機密情報の窃取といった深刻な被害につながります。
  • 内部脅威への対応: 内部の人間が不正な意図を持っていた場合、デフォルトのユーザーネームが知られていることで、推測しやすいパスワードと組み合わせて悪用されるリスクがあります。

対策

Amazon RDSデータベースインスタンスの管理ユーザーネームを一意で推測困難な値に変更することは、上記のすべてのリスクを軽減し、データベースのセキュリティ体制を大幅に強化するための最も基本的なベストプラクティスです。

  • 一意な管理ユーザーネームの設定: データベースインスタンスを作成する際に、デフォルトのユーザーネーム(例: admin, master, root, postgresなど)ではない、組織固有かつ推測困難なユーザーネームを設定します。
  • 強力なパスワードの使用: ユーザーネームだけでなく、複雑で長いパスワードを組み合わせることで、ブルートフォース攻撃に対する耐性をさらに高めます。AWS Secrets Managerなどのサービスを利用してパスワードを安全に管理することを推奨します。
  • 最小特権の原則の適用: 管理ユーザーネームはデータベースのフルアクセス権限を持つため、日常的な操作にはこのユーザーネームを使用せず、特定のタスクに必要な最小限の権限のみを持つ別のユーザーアカウントを作成し、それを使用します。
  • ネットワークアクセス制御の強化: データベースインスタンスへのアクセスを、必要なIPアドレスやセキュリティグループに限定することで、不正なアクセス試行自体を減らします。パブリックアクセスは無効にし、VPNやDirect Connect経由でのアクセスを推奨します。
  • 監査とロギング: データベースログ(監査ログ、一般ログ、エラーログなど)をCloudWatch Logsに送信し、不審なログイン試行や権限昇格の試みを監視します。AWS CloudTrailでRDSのAPI呼び出しを追跡し、変更履歴を監視することも重要です。

修復方法

Amazon RDSデータベースインスタンスの管理ユーザーネームは、インスタンス作成時にのみ設定可能です。既存のインスタンスの管理ユーザーネームを直接変更することはできません。既存のインスタンスを修正するには、スナップショットを取得し、そのスナップショットから新しい管理ユーザーネームを持つ新しいインスタンスとして復元する必要があります。

AWSコンソールでの修復手順

AWSコンソールを使用して、Amazon RDSデータベースインスタンスの作成時に管理ユーザーネームを一意の値に設定します。

既存インスタンスの修復(スナップショットから復元):

  1. 既存のRDSインスタンスのスナップショットを作成:
    • AWSコンソールにログインし、Amazon RDS サービスを開きます。
    • 左側のナビゲーションペインで「データベース」を選択し、管理ユーザーネームを変更したいインスタンスを選択します。
    • アクション」から「スナップショットの取得」を選択し、スナップショット名を入力して作成します。
  2. 新しいインスタンスをスナップショットから復元:
    • 左側のナビゲーションペインで「スナップショット」を選択し、作成したスナップショットを選択します。「アクション」から「スナップショットを復元」を選択します。DBインスタンス識別子: 新しいインスタンスの一意の識別子を入力します。マスターユーザーネーム: ここでデフォルトではない、新しい一意の管理ユーザーネーム(例: my_app_admindb_superuser_prod など)を入力します。マスターパスワード: 新しい強力なパスワードを設定します。その他の設定(インスタンスタイプ、VPC、セキュリティグループ、暗号化など)は、必要に応じて既存のインスタンスと同じか、よりセキュアな設定を選択します。設定内容を確認し、「データベースの復元」をクリックします。
  1. アプリケーションの接続情報の更新: 新しいインスタンスが起動したら、アプリケーションやツールがこの新しいインスタンスと、新しい管理ユーザーネームおよびパスワードで接続するように設定を更新します。
  2. 古いインスタンスの削除(オプション): 新しいインスタンスが正常に機能していることを確認した後、古いインスタンスを削除することができます。データの損失を防ぐため、必ずこのステップを慎重に行ってください。

Terraformでの修復手順

TerraformでAmazon RDSデータベースインスタンスの管理ユーザーネームを設定するには、aws_db_instance または aws_rds_cluster リソースの username パラメータを設定します。既存のインスタンスの username を変更すると、Terraformは新しいインスタンスを作成し、古いインスタンスを削除しようとします(データ損失のリスクがあるため注意が必要です)。安全に既存インスタンスのユーザーネームを変更するには、スナップショットからの復元をTerraformで自動化する必要があります。

新規インスタンスを作成する場合:

# (前提) VPC, サブネットグループ, セキュリティグループは別途定義 (以前のRDSの例などを参照)
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}
resource "aws_subnet" "subnet_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "${data.aws_region.current.name}a"
}
resource "aws_subnet" "subnet_b" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "${data.aws_region.current.name}b"
}
resource "aws_db_subnet_group" "rds_subnet_group" {
  name       = "my-rds-subnet-group"
  subnet_ids = [aws_subnet.subnet_a.id, aws_subnet.subnet_b.id]
}
resource "aws_security_group" "rds_sg" {
  name        = "rds-security-group"
  vpc_id      = aws_vpc.main.id
  ingress {
    from_port   = 3306 # MySQLの場合
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }
}

# Amazon RDSデータベースインスタンス
resource "aws_db_instance" "my_rds_instance" {
  allocated_storage    = 20
  engine               = "mysql"
  engine_version       = "8.0.35"
  instance_class       = "db.t3.micro"
  db_name              = "mydb"
  
  # **重要: デフォルトではない、一意の管理ユーザーネームを設定**
  username             = "myappadmin" # 例: デフォルトの 'admin' や 'root' を避ける
  password             = "MyStrongPassw0rd!" # **強力なパスワードを設定。AWS Secrets Managerとの連携を推奨**

  parameter_group_name = "default.mysql8.0"
  skip_final_snapshot  = true
  storage_encrypted    = true # 暗号化も有効にすることを推奨
  kms_key_id           = "arn:aws:kms:ap-northeast-1:123456789012:key/your-kms-key-id" # CMKのARNに置き換え

  db_subnet_group_name = aws_db_subnet_group.rds_subnet_group.name
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  publicly_accessible  = false
  apply_immediately    = true

  tags = {
    Name        = "MySecureRDSInstance"
    Environment = "Production"
  }
}

# 現在のAWSアカウント情報とリージョンを取得
data "aws_caller_identity" "current" {}
data "aws_region" "current" {}

上記のTerraformコードでは、aws_db_instance リソースの username パラメータに、デフォルトではない一意のユーザーネームを設定しています。

  • username = "myappadmin": ここに、データベースの管理ユーザーネームを指定します。デフォルトのadminrootpostgresなどを避け、推測困難なものにします。
  • password = "MyStrongPassw0rd!": パスワードも同様に、強力なものを設定し、本番環境ではTerraformコードに直接書き込まず、AWS Secrets Managerなどのシークレット管理サービスから取得するように設定することを強く推奨します。

既存インスタンスのユーザーネームをTerraformで変更する際の注意点:

Terraformのaws_db_instanceリソースでusernameを変更すると、Terraformはデフォルトでそのインスタンスを再作成しようとします。これはデータ損失を伴う可能性があります。既存インスタンスの安全なユーザーネーム変更をTerraformで管理する場合、以下の手順を検討してください。

  1. ignore_changes を使用しない場合(データ損失に注意): ユーザーネームを変更すると、Terraformはインスタンスを破棄して再作成します。この場合、データベースのバックアップと復元をTerraformの外部で手動で行うか、またはTerraformでスナップショットからの復元ロジックを別途記述する必要があります。
  2. Terraformでスナップショットからの復元を管理する場合: より複雑になりますが、Terraformで既存インスタンスのスナップショットを取得し、そのスナップショットから新しいユーザーネームを持つインスタンスを復元するロジックを記述できます。これは、現在のTerraformの機能だけでは直接的なリファクタリングが難しく、null_resourceや外部スクリプトの利用が必要になる場合があります。

最も推奨されるアプローチは、新しいセキュアなインスタンスを作成し、データを移行することです。

最後に

この記事では、Amazon RDSデータベースインスタンスの管理ユーザーネームをデフォルトから変更することの重要性について解説しました。このシンプルな設定変更が、ブルートフォース攻撃や認証情報漏洩のリスクを大幅に低減し、データベース全体のセキュリティ体制を強化します。 貴社のRDSインスタンスは、デフォルトではない一意の管理ユーザーネームで保護されていますか?この機会にぜひ設定を確認・強化してみてください。 こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

料金プランを詳しく見る