Amazon Linux2023の移行に伴うSSSDを用いたSSHの検証
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、CyberAgent Group SRE Advent Calendar 2025の初日の記事になります。AL2023への移行に伴い、SSSDとAWSサービスを用いてセキュアなLDAPS認証を実現する技術検証の内容と、その過程で直面したネットワーク設定の課題と解決策を紹介するものです。
はじめに
Amazon Linux 2 (AL2) のサポート終了が近づいており、多くの環境で後継OSへの移行が計画されています。
私たちもEC2インスタンスのOSをAmazon Linux 2023 (AL2023) へ移行するプロジェクトを進めていました。
しかし、移行作業を進める中で、これまでSSHのLDAP認証で利用していた パッケージが、AL2023 (およびRHEL系のディストリビューション) では廃止されていることが判明しました。
この変更により、既存のLDAP認証の仕組みを見直す必要に迫られ、代替策としてSSSD (System Security Services Daemon) をベースとした認証方式への切り替えを検証することにしました。
この記事では、AL2023への移行に伴い、SSSDを用いてLDAPS経由でのSSH認証を実現するまでに行った技術検証の内容と、その過程で直面した課題について紹介します。
目指したアーキテクチャ
今回のOS更改は、単なる移行に留まらず、セキュリティ強化も目的の1つでした。
そのため、LDAPサーバへの接続は暗号化されたLDAPS (LDAP over SSL/TLS) を利用することを前提としました。
最終的に採用したアーキテクチャの概要は以下の通りです。
構成のポイント
LDAPサーバを専用のVPC上に配置し、各アプリケーションが稼働するVPCからは AWS PrivateLink を介して当該LDAPサーバへ接続する構成とします。アプリケーションVPCからのLDAPアクセスは、すべて Network Load Balancer (NLB) を経由させることで集約し、通信経路および制御点を明確にします。
また、LDAPS による TLS 通信は LDAPサーバ本体ではなく NLB 側で終端します。具体的には、クライアント（EC2 上の SSSD）は ldaps://{ドメイン}:636 の形式で NLB に接続し、NLB で TLS 通信を復号したうえで、バックエンドの LDAP サーバへは平文の LDAP (TCP/389) としてトラフィックを転送します。
この構成を採用した理由は、主に以下の3点です。
- 運用負荷の軽減: 証明書を自分で管理することは避けたい
- 影響範囲の限定: VPC内のEC2からNLBまでの通信経路さえTLSで保護されていれば十分
- 既存環境への配慮: 既存のLDAPサーバ側の設定変更を極力避けたかった
証明書管理
証明書の管理には、AWS Certificate Manager (ACM) を利用することにしました。
自己署名証明書を利用する場合、各クライアントへの配布や証明書の有効期限に伴うローテーション作業など、運用コストが高くなる懸念がありました。
ACMには、Amazonが発行するパブリック証明書、AWS Private CAを利用したプライベート証明書、外部CAからインポートした証明書の3つの利用方法があります。
今回はコストと導入の手軽さを優先し、パブリック証明書をNLBに設定する方式を選択しました。
これにより、証明書の取得や更新管理をAWSに任せることができます。
ネットワーク設定の課題と解決策
今回の検証で最も時間を要したのは、ネットワーク周りの設定でした。
特に、AWS PrivateLink (VPC Endpoint と Endpoint Service) を利用した構成になっていたことで、セキュリティグループで通信を許可すべき箇所が複数にわたり、設定が複雑化したことが大きな要因です。
当初はクライアントEC2とNLB間のセキュリティグループを設定すれば接続できると考えていましたが、それだけでは通信が確立できませんでした。
最終的に、以下のすべての箇所で適切なインバウンド・アウトバウンド設定を行う必要がありました。
特に、Interface VPC Endpoint側のインバウンド設定を見落としていたため、接続エラーの原因特定に多くの時間を費やしてしまいました。
AWS PrivateLinkを利用する際は、通信経路上のすべてのコンポーネントでセキュリティグループの設定が必要になる点を意識することが重要です。
まとめ
今回の検証により、TLS終端をNLBに集約してACMで証明書管理を行う構成とすることで、運用負荷を抑えつつ、既存のLDAPサーバの設定変更を最小限にしたまま、Amazon Linux 2023 環境でのLDAPS認証を実現しました。
あわせて、VPCピアリングやAWS PrivateLinkなどのネットワーク構成要素への理解が深まり、複数VPC・複数サービスが関わる環境におけるセキュリティグループ設計の重要性を再認識する良い機会となりました。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。