Posted inセキュリティ

SSH鍵管理の混乱から脱却する：Smallstep証明書によるアクセスの一元化

Security tutorial - IT technology blog
Security tutorial - IT technology blog

クイックスタート：5分で最初のSSH証明書をデプロイする

50台以上のサーバーで生のSSH鍵を管理するのは、単なる面倒な作業ではありません。それは、セキュリティ上の大惨事の予兆です。ある時、私のrootアカウントが1時間に4,500回ものブルートフォース攻撃を受けた際、従来の鍵管理はあまりに遅く、リスクが高いことに気づきました。SSH証明書がどのようにこの問題を即座に解決するかを確認するために、Smallstepを使用して最小構成の認証局（CA）を今すぐセットアップしてみましょう。

まず、コントロールマシン用のstep CLI and step-caを取得します。ここではUbuntu 22.04を使用しています：

wget https://dl.step.sm/gh-release/cli/gh-release-header/v0.24.4/step-cli_0.24.4_amd64.deb
sudo dpkg -i step-cli_0.24.4_amd64.deb

wget https://dl.step.sm/gh-release/ca/gh-release-header/v0.24.2/step-ca_0.24.2_amd64.deb
sudo dpkg -i step-ca_0.24.2_amd64.deb

次に、CAを初期化します。このコマンドは、アイデンティティを署名するための設定とルート鍵を生成します：

step ca init --name="My-Internal-CA" \
    --provisioner="[email protected]" \
    --dns="localhost" \
    --address=":9000"

別のターミナルウィンドウでCAサーバーを起動します：

step-ca $(step path)/config/ca.json

ユーザー鍵を署名するには、次のコマンドを実行します：

step ssh certificate [email protected] id_rsa

これでid_rsa-cert.pubが作成されます。非常に簡単です。すべてのノードに公開鍵をコピーする代わりに、サーバーに一度だけCAを信頼するように設定すれば、二度とauthorized_keysを触る必要はありません。これは、インフラストラクチャへのアクセス処理における根本的な転換です。

従来のSSH鍵の真のコスト

私たちは皆、経験があるはずです。RSA鍵を生成し、ssh-copy-idを実行し、二度と触らなくて済むことを願う……。これは個人プロジェクトなら機能します。しかし、チームが大きくなると壁にぶつかります。DevOpsエンジニアが退職したとき、すべての本番インスタンスからその人の公開鍵を手動で削除しなければなりません。一つでも忘れたら？ 永続的なバックドアを放置することになります。

さらに、「初回使用時の信頼」（TOFU）という host key verification の警告を覚えていますか？ ほとんどのエンジニアは深く考えずに「yes」と入力してしまいます。この習慣は、中間者（MITM）攻撃を狙う攻撃者にとって格好の餌食です。

なぜ証明書が優れているのか

SSH証明書は、第三者機関である「認証局（CA）」を導入します。これはデジタルパスポート制度のようなものだと考えてください。サーバーはあなたを個人的に知る必要はありません。あなたのパスポート（証明書）を発行した政府（CA）を信頼していればいいのです。

  • 空のauthorized_keys： サーバーが必要とするのはCAの公開鍵だけです。証明書がそのCAによって署名されていれば、アクセスが許可されます。
  • ロールベースのアクセス： 特定のユーザー名やロールを証明書に直接埋め込むことができます。
  • 組み込みの有効期限： 8時間や12時間だけ有効な証明書を発行できます。夕方の6時にノートパソコンが盗まれても、翌朝には泥棒のアクセス権は消滅しています。

Smallstepの利点

Smallstepは、これを実用的なものにするエンジンです。自動化のために設計された、軽量で安全なCAであるstep-caを提供します。手動での署名は不要です。SmallstepをOkta、Google、GitHubなどの既存のアイデンティティプロバイダーにリンクさせることができます。開発者がSSO経由でログインすると、Smallstepが当日のみ有効な一時的な証明書を自動的に発行します。

高度な設定：ホストとユーザーの信頼の自動化

SSHの警告を完全に無くすには、双方向の信頼を設定する必要があります。

1. サーバーにCAを信頼させる

対象のLinuxサーバーに、あなたのCAが正当であることを教える必要があります。まず CAの公開SSH鍵を取得します：

step ssh config --ssh-ca-user

この鍵をサーバー上の/etc/ssh/trusted-user-ca-keys.pemに保存し、/etc/ssh/sshd_configを更新します：

# SSH設定をCA鍵に向ける
TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem

sudo systemctl restart sshでサービスを再起動します。これで、CA署名済みの証明書を持つユーザーなら誰でもアクセスできるようになります。手動での鍵同期はもう不要です。

2. 「不明なホスト」警告をなくす

サーバーにも証明書が必要です。TerraformやAnsibleによるプロビジョニング中に、ホスト証明書を署名できます。サーバーの/etc/ssh/sshd_configに以下を追加します：

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

ローカルマシンの~/.ssh/known_hostsに、CAのホスト鍵を追加します：

@cert-authority * ecdsa-sha2-nistp256 AAAAE... (あなたのCA公開鍵)

これで、SSHクライアントはCAが署名したすべてのサーバーを信頼するようになります。プロンプトもMITMのリスクももうありません。

3. ‘step ssh login’ によるSSO連携

究極の形は、step ssh loginワークフローです。チームが1日を始めるとき、コマンドを1つ実行します：

step ssh login [email protected]

ブラウザが立ち上がり、会社のSSOで認証すると、Smallstepが12時間有効な証明書をSSHエージェントに注入します。ユーザーは秘密鍵ファイルを目にすることさえありません。シームレスで、信じられないほど安全です。

本番環境の現実：現場からの教訓

証明書への移行には、戦略の変更が必要です。高トラフィックな環境にこれをデプロイして学んだことを共有します。

失効戦略

短寿命の証明書（16時間未満）の場合、通常は失効リスト（CRL）は必要ありません。鍵が漏洩したとしても、有効期限が切れるのを待つだけです。より長寿命のクレデンシャルの場合、Smallstepは鍵失効リスト（KRL）をサポートしています。侵害が発生した場合は、サーバー上のKRLを更新して、特定のIDを即座にブロックします。

信頼性がすべて

step-caを適当なターミナルやscreenセッションで実行しないでください。systemdユニットファイルを使用しましょう。CAは今やインフラの心臓部であるため、チームが数人以上に増えたら、高可用性（HA）構成にするか、信頼できるロードバランサーの背後で運用してください。

「非常用」プロトコル

Smallstepを最初に導入するときは、管理者のauthorized_keysに従来のSSH鍵を一つ残しておいてください。CAの信頼設定を間違えたときに、自社のデータセンターから締め出されるのは避けたいものです。自動化が盤石になったら、これらの静的な鍵を完全に廃止できます。

監査と可視化

Smallstepは、すべての証明書リクエストをログに記録します。これにより、完璧な監査証跡が作成されます。「誰が、いつ、何にアクセスしたか」を正確に把握できます。これらのログをGrafanaやELKスタックにパイプして、リアルタイムで可視化しましょう。数千のノードに散らばる.sshフォルダを漁るのと比べれば、劇的な進化です。

SSH証明書への切り替えは、心の平穏を得るための投資です。手作業でエラーが発生しやすいファイル管理を、スケール可能なアイデンティティ駆動型のシステムに置き換えることができます。深夜にセキュリティの不安に怯えることはもうありません。クリーンで自動化されたアクセスが手に入ります。

Share:
Tags: