😆

RDS SSL/TLS証明書をローテーションする方法

2024/07/20に公開

AWS

SSL 証明書

RDS

tech

背景

AWSからRDS SSL/TLS証明書の更新のメールが来ました。

# メール内容を一部抜粋

You are receiving this message because your AWS Account has one or more Amazon RDS, or Amazon Aurora database instances in the AP-NORTHEAST-1 Region using a SSL/TLS Certificate that is expiring on August 22, 2024.
A list of your affected resources can be found in the 'Affected resources' tab of your AWS Health Dashboard.
This is a follow-up notification for SSL/TLS CA certification expiration. If you believe you have already finished this work and still received this email, it is likely because you created new instances using the 2019 Certificate Authority (CA). After January 25, 2024 all newly created instances that do not explicitly specify a different CA will use the ‘rds-ca-rsa2048-g1’ CA. For information on setting an account level CA override, see the modify-certificates API documentation [1].

# 日本語訳
# 以下のメッセージは、お客様のAWSアカウントが、2024年8月22日に有効期限が切れるSSL/TLS証明書を使用しているAP-NORTHEAST-1リージョンのAmazon RDSまたはAmazon Auroraデータベースインスタンスを1つ以上持っているために送信されています。
# 影響を受けるリソースのリストは、AWS Health Dashboardの「影響を受けるリソース」タブで確認できます。
# これは、SSL/TLS CA証明書の有効期限に関するフォローアップ通知です。既にこの作業を完了しているとお考えであっても、このメールを受け取った場合は、2019年の証明書認証機関（CA）を使用して新しいインスタンスを作成した可能性があります。2024年1月25日以降、異なるCAを明示的に指定しない限り、新しく作成されたすべてのインスタンスは「rds-ca-rsa2048-g1」CAを使用します。アカウントレベルでCAを上書きする方法については、modify-certificates APIのドキュメントをご覧ください。

いろんな記事に対応方法が記載されていましたが、個人的には来たメールの内容の把握と対応方法を見つけるのに時間がかかったので、他の人にも参考になるようにまとめてみました。

よかったらRDS SSL/TLS証明書更新時の参考にしていただけると幸いです。

メールの内容の把握と対応方法

まず、AWSから来たメールの内容を把握いたします。

メールの内容は、Amazon RDSやAmazon Auroraのデータベースに接続する際、SSL/TLSを使用しているなら、有効期限が切れる前に新しいCA証明書に更新する必要があるということです。

対応方法としては、こちらのドキュメントを参考にしました。手順は下記の通りです。

手順

影響を受ける Amazon RDS リソースを特定する
データベースクライアントとアプリケーションの更新
非本番環境の RDS インスタンスで CA ローテーションをテストする
実稼働 RDS インスタンスを安全に更新する

この後、１つずつどのようなことをおこなったのか具体的に説明していきます。

影響を受ける Amazon RDS リソースを特定する

まず、AWS RDSコンソール > 左メニューバー「証明書の更新」で今回SSL証明書の期限切れ通知メールがきている対象のDBインスタンスを特定します。（Amazon Auroraは使用していないので説明は割愛いたします。）

下記画像は公式ドキュメントを抜粋したものです。この画像では、database-1,database-2 が対象となります。

2. データベースクライアントとアプリケーションの更新

ここは少し苦戦しました。こちらのドキュメントを読んでも対応方法を理解するのに時間がかかったからです。

ここで実行したことは下記の2つです。

①新しいCA証明書をダウンロードし、クライアント側とアプリケーションの信頼ストア（トラストストア）を更新する

②使用しているDBエンジンがSSL/TLS 接続しているかどうかの確認

①はこちらの新しいCA証明書バンドルをクリックし、ダウンロードしました。

ただ、クライアント側のアプリケーション（Macの場合「キーチェーンアクセス」というアプリ？これがトラストストアの役割になると判断。）にこの証明書を登録する必要があったので、ただダウンロードするだけでなく、こちらの記事を参考にダウンロードした証明書をダブルクリックし、「この証明書を信頼するとき」という項目を「常に信頼」といったステータスに変更しました。

その時の上記の内容を実行した後の画面が下記の通りです。「常に信頼」といったステータスに変更することで、赤い×マークから水色の＋マークに変化しました。

これで、ダウンロードした新しいCA証明書をクライアント側アプリケーションへの登録をする作業は完了したと思われます。

次に②の対応する理由としては、SSL/TLS通信を使用していた場合、証明書の有効期限が切れると、RDS DBインスタンスへの接続が失われる可能性があるからです。

使用していたDBエンジンがPostgresだったので、対応としてはこちらのドキュメントを参考にしました。

こちらのドキュメントより、SSL/TLS接続を使用しているかの確認は、「クエリを実行」か「パラメータ」で確認できると思います。

クエリ実行での確認の場合、下記のコマンドをpsql内で実行してください。（ドキュメントに記載あり）

SELECT datname, usename, ssl, client_addr 
  FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
  WHERE ssl is true and usename<>'rdsadmin';

実行結果は下記のようになりました。接続に関する情報は返ってきていないので、SSL/TLS接続は使用していないようです。

SELECT datname, usename, ssl, client_addr
FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
WHERE ssl is true and usename<>'rdsadmin';

 datname | usename | ssl | client_addr 
---------+---------+-----+-------------
(0 rows)

ただ、ドキュメントには「このクエリでは、クエリ実行時点の接続のみが表示されます。結果が表示されなくても、SSL 接続を使用しているアプリケーションが存在しないわけではありません。」と記載があったので、この検証方法でSSL/TLS接続していないということを確実に証明できたわけではないようです。

パラメータを用いてSSL/TLS接続しているかの確認をする場合、rds.force_sslパラメータを使用することになります。

手順としては、AWS RDSコンソール > 「パラメータグループ」をクリック > 対象のDBインスタンスをクリック > 「パラメータ」という項目のフォームに「rds.force_ssl」と入力する　といった流れになります。

すると、下記のような結果になりました。

こちらのドキュメントより、rds.force_ssl パラメータの値は、PostgreSQL バージョン 15 より前 → 0（オフ）、PostgreSQL バージョン 15 以降 → 1（オン）がデフォルト値として設定されるようです。

使用しているPostgreSQL はバージョン11であったため、0（オフ）になっており、SSL/TLS接続は使用していないことを確認することができました。

3. 非本番環境の RDS インスタンスで CA ローテーションをテストする
4. 実稼働 RDS インスタンスを安全に更新する

この２つに関しては、対応方法は基本的には同じなので、まとめて説明いたします。（流れとしては、3を実行し問題なければ4を実行する流れになります）

ただ、ここに関しては、ドキュメントがわかりやすかったので、対応にはそこまで苦戦はしないと思います。

対応方法の流れとしては、AWS RDSコンソール > 対象のDBインスタンスをクリック > 「変更」タブをクリック > 「認証機関」という項目で設定されているCAをrds-ca-rsa2048-g1に変更（もともと設定していたCAはrds-ca-2019でした） > 「続行」をクリック > 「すぐに適用」を選択 > 「DBインスタンスを変更」をクリック　という流れでした。

この対応を行うことで、今回のRDSのSSL/TLS証明書の更新のための対応は完了すると思います。

ただ、１つ注意点として、上記の対応方法を実行する前に、SSL/TLS証明書更新時に使用しているDBインスタンスが再起動するかどうか確認しておくことをお勧めいたします。

理由としては、RDSのDBインスタンスが再起動するなら、影響がないタイミングでSSL/TLS証明書更新の対応をおこな必要があるためです。

こちらの対応方法は、ドキュメントに記載されているので、参考にしていただけると幸いです。

自分はAWS CloudShellを使用し、「aws rds describe-db-engine-versions ~ 」コマンドを実行し、レスポンスの中にある SupportsCertificateRotationWithoutRestart フィールドの値を確認しました。

ドキュメントより、SupportsCertificateRotationWithoutRestart フィールドの値が true になっていれば再起動しないようです。

下記に実行コマンドの例と実行結果を示しておきます。実行結果を見る限り、再起動はしないようです。

# CloudShellで下記コマンドを実行
$ aws rds describe-db-engine-versions --default-only --engine postgres
{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "16.3",
            "DBParameterGroupFamily": "postgres16",
            "DBEngineDescription": "PostgreSQL",
            
  ・・・
  
            "Status": "available",
            "SupportsParallelQuery": false,
            "SupportsGlobalDatabases": false,
            "MajorEngineVersion": "16",
            "SupportsBabelfish": false,
            "SupportsLimitlessDatabase": false,
            "SupportsCertificateRotationWithoutRestart": true,
            "SupportedCACertificateIdentifiers": [
                "rds-ca-2019",
                "rds-ca-ecc384-g1",
                "rds-ca-rsa4096-g1",
                "rds-ca-rsa2048-g1"
            ],
            "SupportsLocalWriteForwarding": false,
            "SupportsIntegrations": false
        }
    ]
}

最後に、上記の3の対応が完了した後、RDS DBインスタンスの「接続とセキュリティ」の項目でCAが変更できているかを確認しました。

結果は下記の通りです。

無事更新されているようです。3実行後、4も実行し同様の結果になっていることを確認しました。

まとめ

今回初めてRDS SSL/TLS証明書の更新の対応を行いました。

正直普段AWSリソースの設定を変更することがないので、内心ビビりながら対応いたしました。

ですが、なんとか対応することができました。

今回の件を糧に今後はAWSのリソースの設定の切り替えをスムーズにできるように少しずつAWSの勉強をしていきます。

参考

https://www.k-friendly.com/17216

背景

メールの内容の把握と対応方法

まとめ

参考

Discussion