クラウド社会におけるSSHの役割とOkta ASAでSSHアクセスを管理　

Ivan Dwyer, July 6, 2020

米国を代表する作家のマーク・トウェインは、1897年5月に自身の追悼記事が出されたことに応えて、「私の死のニュースは大いに誇張されている」と書いています。100年近くたった1995年、フィンランド人コンピューター科学者のタトュ・ウルネン（Tatu Ylönen）氏は、Secure Shell（SSH）と呼ばれる安全なトランスポートプロトコルを作成しました。一見これらの2つの出来事には何の関係もないようにみえるかもしれませんが、「認識」に関して共通する部分があります。

最も実用的な言い方をすれば、SSHを使用することで、ユーザーはコマンドラインインターフェイス（CLI）を介してLinuxベースのマシンとの安全なリモート接続を確立できます。SSHは、セキュアなサーバーアクセスのデファクトスタンダードであり、クラウドでのインフラストラクチャの運用が大きく変化したにもかかわらず、長年使用され続けてきた実績を持ちます。

Oktaでは、SSHの基盤となるセキュリティプロパティを適合させることにより、リソースが動的かつ一時的なクラウド運用モデルへの移行を受け入れています。Oktaのお客様は、Oktaアドバンストサーバーアクセス（Okta ASA）を使用し、チームがSSHを安全に使用できるようにアイデンティティとリモートアクセスの制御を安全に自動化しています。また、1か月あたり100万以上（さらに増加中）のSSHログイン登録を記録した現在、重要な採用のマイルストーンに達しました。

この記事では、クラウド運用モデルを取り巻くいくつかのトレンド、リモートアクセスの保護においてSSHが引き続き果たしている役割、そしてOktaがお客様の抱える課題を巧みに解決する方法を取り上げます。

大いなる力には大いなる責任が伴う

Linuxサーバーへのリモートアクセスのデファクトスタンダードとして、企業のネットワークに侵入しようとする攻撃者にとっては、当然ながらSSHが一般的なターゲットになります。トランスポートプロトコルは本質的に安全ですが、その下支えとなる資格情報のメカニズムでは人為的エラーが発生しやすく、甚大な被害を引き起こす可能性があります。SSH鍵認証は、信頼の証明として設計された暗号鍵のペアであり、犯罪者の手に渡らないようにするための細心の注意が必要です。SSH鍵認証とアイデンティティの間のリンクを保証する方法はないので、多くの点においては占有することが最大の強みとなります。

そのため、企業はこれまで以下のいずれかを余儀なくされてきました。

  • ユーザーが個人のSSH鍵認証を定期的に管理してローテーションさせるセキュリティポリシーを実装する（最も簡単、安全性が最も低い）。
  • SSH鍵を保存できるセキュアなボールトサービスを運用し、オンデマンドで確認する（より難しく、より安全）。
  • 特権アクセス管理製品を購入して展開し、リモートアクセスのゲートウェイとして機能させる（最も難しく、安全性が最も高い）。

SSH鍵認証のパターンが見えてきますね。ほかの多くのことと同様、頑張っただけの成果を得ることができるのです。しかし、セキュリティは変化しています。しかも高速で変化しているのです。第一に、最も労苦を伴う解決策が必ずしも最も安全ではあるわけではありません。また、それだけの労力を費やす余力がある人などいないということです。誰もがより少ない労力でより多くの成果を上げることを迫られている状況で、セキュリティチームはビジネスを邪魔せずに企業を保護するという課題にも直面しており、非常に厄介な状況に陥っていると言えます。

Oktaは、この継続的なバランス調整を理解し、市場で最も安全で最も使いやすいソリューションとなるように製品を設計しています。「このクラウドの時代においてSSHの役割は終わった」という認識について検討したいと思います。また、お客様がOkta ASAでより大きな成果を達成できるように支援する方法についても紹介します。

SSHアクセスの代用であるKubernetesの課題

クラウド運用モデルへの移行に伴い、構成管理プレーン/オーケストレーションレイヤー/CLI/ランタイム/サービスメッシュ/開発環境プラットフォームとしてKubernetesの人気が高まっています。そこで、「誰もがKubernetesを使っている。もうSSHアクセスは必要ない」という声が聞こえてくるようになりました。

弾力的なマルチクラウドインフラストラクチャの管理から人間の介入がすべて排除された、統合された抽象化レイヤーは、確かに理想的です。「クラウドのオペレーティングシステム」と評されるKubernetesは、確かにそのような存在になる準備が整っています。しかし、SSHアクセスとは異なるまったく新しい複雑さと考慮事項ももたらします。以下のようなシナリオでは、人間の介入が依然として必要とされます。

  • 基盤となるホストにログインして、診断スクリプトの実行、ログの検査、ネットワーク問題のデバッグなどを実行する
  • ターゲットの環境、サービス、ランタイムなどを記述・構成するためのYAMLコードを記述してデバッグを実行する
  • ネットワーク、インフラストラクチャ、サービスなどのパフォーマンスを監視する

SSHは、イノベーションと変化の波を受けながらも大きな役割を果たしています。これは、ユーザーとホストOSの間の堅牢な直接接続を置き換えることができないためです。自動化が最も進んだ環境でも、緊急時には人間のアクセスが必要です。しかし、それ以上に、自動化にはセキュリティ制御も必要となります。SSHは、人的アクセスとサービスレベルのアクセスの両方で要件を十分に満たしています。

ここで私たちが思い浮かべるSSHのイメージは、システム管理者がデスクに座り、「ssh <ホスト名>」と入力して、端末から単一のLinuxサーバーに接続する光景ではないでしょうか。ユースケースとしてはユーザーからサーバーへの直接認証・ログインすることが一般的ですが、以下の場合にはSSHの使用も一般的です。

  • 開発者が、一度に多数のサーバーに接続するスクリプトを作成して実行し、一連の診断テストを実行する
  • 構成管理ソフトウェア（Terraform、Chef、Puppet、Ansibleなど）が、ターゲットホストに接続してローカルで変更を加える
  • CI/CD自動化ツールが、本番サーバに接続してランタイムを構成し、ソフトウェアビルドを推し進めます。

SSH鍵を持っているのは誰？

SSH鍵の問題に戻りましょう。SSHを支える従来のPKI（公開鍵基盤）は、鍵交換が信頼を付与するのに十分な意味を持っていた時代に構築されたものです。中核的な問題は、SSH秘密鍵の所有権がアイデンティティプロファイルと同じであるという誤った仮定にあります。「アリスの秘密の鍵」と言いますが、最初に鍵ペアを生成したのがアリスだったこと、または現在秘密鍵を所有しているのがアリスだけであることを検証できる、関連付けられた認証プロセスはありません。

これらのSSH鍵が発行され、動的なインフラストラクチャと一連のクラウドサービスに分散されると、課題はさらに複雑化します。各SSH公開鍵は、時間の経過とともに多くの権限を付与します。存続期間が長いほど、リソースと共有される可能性が高くなり、追跡し、その後に無効にすることが非常に困難になります。このモデルでは、時間は修正できないバグと同じです。

ゼロトラストの世界では、意味のある信頼の証明は、人（またはサービス）が既知のデバイスから特定の時間に特定のリソースにアクセスできることを定めるポリシーに正しく準拠しています。それは必ずしも資格情報自体に関係するものではなく、リクエストを取り巻くコンテキストに関係するものです。その場合も、作成された証明に関連付けられたアイデンティティと許可を表す方法がまだ必要です。

SSHクライアント証明書の登場

幸いなことに、OpenSSHのコアテクノロジーは時間の経過とともに進化し、2011年にSSH鍵ではなくクライアント証明書を使用して認証する機能が導入されました。メタデータを保持しない標準のSSH鍵とは異なり、クライアント証明書は暗号技術により検証可能なメタデータオブジェクトであり、ユーザー名やロールなどを挿入できます。しかし、最も重要であると言ってほぼ間違いないことは、有効期限を持つ点でしょう。

クライアント証明書を使用すると、SSHアクセスはアイデンティティを中心とする認証と承認のワークフローに従うことができます。このワークフローでは、コンテキストに応じたアクセス決定に一致するように厳密に範囲指定された資格情報が、オンデマンドで作成されます。単一のリクエストに単一の資格情報が対応し、簡潔に行うことができます。有効期限が厳しいため、クリーンアップが不要になり、前述のとおり、資格情報の追跡、管理、およびローテーションに伴う負担が軽減されます。SSH鍵ではバグであった時間が、強みの1つになったのです。

タダほど高いものは今でもありません。有効な要求ごとにこれらのクライアント証明書を生成できる公開鍵基盤（PKI）システムの構築と維持には、相当の作業と継続的な運用上の責任が伴います。ここで効果を発揮するのがOktaです。自分で自分の認証を操るべきではないことを誰もが承知しているのと同じく、自分で自分のPKIを操るべきではありません。

Okta ASAでSSHアクセスを管理する方法

Okta ASAのリリース以来、サーバーアクセスでは何よりもまずアイデンティティが問題になるという認識を持つお客様が増えています。それぞれに異なる制御を備えた異なるアクセス管理システムは、望まない複雑化をもたらし、管理不能な領域を生み出します。アイデンティティでアクセスを統合できれば、それだけメリットが大きくなります。まず市場をリードするプラットフォームを使用することで、Linuxサーバーのようなアイデンティティ中心のリソースへアクセスを拡張することが自然な流れとなります。

Okta ASAでは、SSHログインは使い慣れたシングルサインオンのエクスペリエンスに従うようになり、認証および承認されたリクエストは、背後で「一時的資格情報」を使用して作成されます。ユーザーから見ると、SSHアクセスを使用しているだけです。一方で、セキュリティチームにとっては、多くの問題が解決されることになります。

OKta アドバンストサーバーアクセス(Okta ASA) のエンドユーザーエクスペリエンス

ユーザーは、ローカルのSSHツールとのインターフェイスを提供する軽量クライアントアプリケーションをワークステーションにインストールします。クライアントアプリケーションは、実行するためにマシンに対する管理者権限を必要とします。Oktaに登録されたサーバーは、ローカルのアカウントおよびポリシー管理を実行し、ログインイベントを捕捉する軽量エージェントを実行します。クライアント証明書認証を有効にするため、OpenSSHは、有効な認証メカニズムとしてOktaによって署名された証明書を信頼するようにローカルで構成されます。これは重要な詳細情報であり、基盤のPKIシステムを取り上げる際に説明したいと思います。

サーバーにログインしようとするユーザーは、Okta経由で認証され、お客様が構成したサインオンポリシーが適用されます。これには、多要素認証やデバイスの信頼が含まれます。認証されたユーザーは、ターゲットサーバーのロールベースのアクセス制御（RBAC）に基づいて認証されます。すべて確認されると、Okta ASAは、要求に応じて範囲指定された一時的なクライアント証明書を作成します。このクライアント証明書がクライアントアプリケーションに提供され、クライアントアプリケーションはその証明書をメモリ内で使用して、ターゲットサーバーとの安全な直接接続を確立します。

これが画期的なのは、Oktaが巧みに構築したSaaSの背後で非常に多くのPKIの複雑さが抽象化され、使い慣れたシームレスなシングルサインオンエクスペリエンスが提供されていることにあります。では、舞台裏で起こっている複雑さとは、どのようなものでしょうか？

動的なクライアント証明書アーキテクチャ

高可用性、耐障害性、安全性を備えたSaaSプラットフォームを運用するには、多くの作業が必要です。そこにPKIを追加すると、負担は非常に大きなものとなります。そのため、同等のシステムを社内で構築することは決してお勧めしません。Okta ASAの基盤となるクライアント証明書アーキテクチャは、2018年7月にOktaが買収したScaleFtを起源とします。

Oktaの設計の独自性は、従来の意味で認証局（CA）を運用していないことにあります（証明書が長期間有効であるため、信頼の連鎖が極めて重要となるWeb PKIを考えてください）。Oktaは、CAアーキテクチャをお客様のクラウドインフラストラクチャ環境と同様に動的なものとして扱い、独立したSSHログインごとに、特定のサーバーグループに対してオンデマンドで一時的なクライアント証明書を作成できるサービスをスピンアップします。

Okta ASAのCAアーキテクチャ

このCAアーキテクチャの主な目的は、技術的に可能な限り、各クライアント証明書の範囲を最小化することです。当然ですが、署名された資格情報として、それぞれの暗号化プロパティは依然として重要です。Oktaは、AWS KMSをルート署名サービスとして使用し、その基盤となるセキュリティプロパティと可用性の高い設計を活用しています。Okta ASAでは、さまざまなAPIイベントに基づいて多数のタスクを実行する暗号化サービスを運用しています。

ここで最も関連性の高いイベントは、プロジェクト作成とSSH接続です。

  • 新しいOkta ASAプロジェクトが作成されると、SHA-256の暗号化された署名鍵が作成されます。サーバーが各ASAプロジェクトに登録されると、ローカルのOpenSSHは、その鍵によって署名されたクライアント証明書を信頼するように構成されます。プロジェクトは、サーバーに対するロールベースのアクセス (RBAC) の承認範囲を表します。したがって、専用の署名鍵を使用することで資格情報の一致も制限されます。
  • 特定の時点において、デバイス上のユーザーに対してSSHログインが認証され許可されると、ユーザーとデバイスのメタデータを使用し、その有効性を制限するための短い有効期限を持つ、新しいクライアント証明書が作成されます。これは、ユーザーのクライアントアプリケーションが、ターゲットサーバーとのセキュアなSSH接続を確立するために、エンドユーザーのエクスペリエンスワークフローに従って使用するクライアント証明書です。有効期限が短いため、使用後のクライアント証明書をクリーンアップする必要はありません。

資格情報が無秩序に増加するリスクを軽減するため、企業もベンダーも多くの時間とコストをかけてきました。Oktaは、この問題の核心に対応しています。資格情報のリスクを軽減する最善の方法は、その有用性をなくすことです。

SSH鍵を使用せず、1か月でSSHログイン100万回達成。

ここで、先に触れた画期的なマイルストーンの話に戻りましょう。各ターゲットサーバーにインストールされるサーバーエージェントは、ユーザーとデバイスに帰属するすべてのログインイベントを捕捉します。このログインイベントは、共有アカウントや共有資格情報を使用して取得するよりも強力な監査イベントを提供します。

AWS、GCP、Azure、またはオンプレミスのサーバーフリートを保護するため、Oktaのお客様がアドバンスドサーバーアクセス（ASA）を採用するのに伴って、サーバー登録とSSHログインイベントも増加し続けています。そしてOktaは、SSH鍵を使用せずに1か月で100万回のSSHログインというマイルストーンに到達し、資格情報の無秩序な増加のリスクを大幅に軽減しました。

Okta ASA経由による1か月あたりのSSHログイン成功数合計

SSHは今後も存続

1897年に追悼記事が出されたマーク・トウェインは、実際には1910年4月に他界しました。その間に、さらに小説2作と複数の短編を完成させています。同様に、SSHは今後も存在感を発揮し、変化するユースケースに適応すると見込まれます。文学に当てはまるように、セキュリティでも時を経て証明された実績には勝てません。

OktaがSSHを正しく使用する（そしてSSHのメリットを生かす）方法については、Oktaアドバンストサーバーアクセス（ASA）の概要で詳細をご覧ください。また、デモをリクエストしていただくこともできます。