1. 管理者ガイド
  2. SSHキー管理の概念

16 SSHキー管理の概念

セキュア・シェル(SSH)は、ホストのリモート管理と操作に使用するプロトコルです。

  • SSHプロトコル
    セキュア・シェル(SSH)は、リモート・ホストに安全にログインするためのプロトコルです。ほとんどの組織では、ユーザーは管理目的、コマンドの実行、トンネリングまたはファイルのコピーのために、日常的にSSHソフトウェアを使用してリモート・ホストにログインします。
  • SSH公開キー認証
    クライアント認証は、パスワード認証、ホストベース認証、公開キー認証などのユーザー認証方法のいずれかによって実行できます。公開キー認証では、公開キーと秘密キーのペアを使用して、セキュア・シェル(SSH)サーバーに接続するユーザーのアイデンティティを確立します。
  • SSHプロトコルのOpenSSH実装
    OpenSSHは、Oracle Linuxで使用可能なセキュア・シェル(SSH)プロトコルの実装であり、一般にLinuxおよびUnixベースのオペレーティング・システムで使用できます。
  • SSH公開キー認証の課題
    次の各項では、SSH公開キー認証で直面する課題について説明します。
  • Oracle Key VaultによるSSHサーバーへのアクセスの一元的な制御
    Oracle Key Vaultでは、セキュア・シェル(SSH)サーバーへのアクセスを一元的に管理できます。一元化されたアクセス制御により、セキュリティが向上し、脅威への迅速な対応が可能になり、人為ミスが少なくなり、大規模な認可管理が簡略化されます。
  • Oracle Key VaultによるSSHユーザー・キーの管理
    Oracle Key Vaultでは、SSHクライアント・ユーザーのセキュア・シェル(SSH)キー・ペアを一元的に管理できます。
  • Oracle Key VaultとSSHの統合
    Oracle Key Vaultでは、セキュア・シェル(SSH)キーの管理に加えて、SSHサーバーへのアクセス制御も個別に実行できますが、SSHキーとSSHサーバーのアクセス制御の両方をOracle Key Vaultで一元的に管理することが理想的です。
  • SSHサーバーおよびクライアント・エンドポイントでサポートされているプラットフォーム
    Oracleでは、SSHサーバーおよびクライアント・エンドポイントで64ビットのプラットフォームがサポートされています。

16.1 SSHプロトコル

セキュア・シェル(SSH)は、リモート・ホストに安全にログインするためのプロトコルです。ほとんどの組織では、ユーザーは管理目的、コマンドの実行、トンネリングまたはファイルのコピーのために、日常的にSSHソフトウェアを使用してリモート・ホストにログインします。

セキュア・シェル(SSH)は、telnetなどの安全性の低いリモート・ホスト・アクセスの手段と、rcpなどの安全性の低いリモート・コピーの手段に取ってかわりました。

クライアント・サーバー・アーキテクチャのセキュア・シェル(SSH)プロトコルは、トランスポート層プロトコル、ユーザー認証プロトコルおよび接続プロトコルの3つのコンポーネントで構成されています。SSHクライアント・ユーザーとは、SSHクライアント・ソフトウェアを実行しているクライアント・ホストのユーザーやプロセスのことです。SSHサーバーとは、SSHサービスを実行しているホストのことです。SSHクライアント・ユーザーは、SSHサーバーとの接続を開始します。このプロトコルでは、サーバーを認証し、暗号化されたセッションを確立して、クライアント・ユーザーの信頼性も確立します。

SSHプロトコルには、多数の実装があります。OpenSSHは、GNU/LinuxとUNIX系のオペレーティング・システムでは一般的なオープン・ソースの実装です。

図16-1 SSHプロトコル


図16-1の説明が続きます
「図16-1 SSHプロトコル」の説明

親トピック: SSHキー管理の概念

16.2 SSH公開キー認証

クライアント認証は、パスワード認証、ホストベース認証、公開キー認証などのユーザー認証方法のいずれかによって実行できます。公開キー認証では、公開キーと秘密キーのペアを使用して、セキュア・シェル(SSH)サーバーに接続するユーザーのアイデンティティを確立します。

接続が設定され、暗号化と整合性のアルゴリズムがネゴシエートされると、クライアントは認証されます。公開キー認証では、クライアント・ユーザーがRSAまたはDSAの秘密キーと公開キーのペアで構成されている必要があります。秘密キーは、一般にidentity keysと呼ばれます。秘密キーは、クライアント・ユーザーのみが使用できます。公開キーはSSHサーバーと共有され、authorized keyと呼ばれることもあります。SSHプロトコルに使用する公開キーと秘密キーのペアは、SSHユーザー・キーまたはSSHキーと呼ばれることもあります。

秘密キーの所有が、認証の基礎になります。公開キー認証の場合、SSHクライアント・ソフトウェアは秘密キーを使用することで署名を生成して、サーバーはクライアントに関連付けられている公開キーを使用することで署名を検証します。セッションは、署名が有効な場合に作成されますが、SSHユーザーは別の認証を受ける可能性があります。

SSHサーバー

SSH公開キー認証で使用される最も一般的な用語は、次のとおりです:

SSHサービスを実行しているホスト。クライアント・ユーザーは、SSHサーバーへの接続を確立し、SSHサーバー・ホストのユーザーとして操作できます。

SSHクライアント

クライアント・ユーザーがSSHサーバーとの接続の確立をここから試みます(ホスト)。

SSHクライアント・ユーザーまたはSSHユーザー

SSHサーバーとの接続を確立しようとしているプリンシパル(ユーザーまたはホスト)。

SSHユーザー・キー・ペアまたはSSHキー・ペア

SSH接続の設定に使用されるSSHユーザーの公開キーと秘密キー。Oracle Key Vault 21.7では、キー・サイズが2048、3072および4096ビットのRSAアルゴリズムのみがサポートされています。

SSHユーザー・キーまたはSSHキー

SSH接続の設定に使用されるSSHクライアント・ユーザーの公開キーまたは秘密キー。

親トピック: SSHキー管理の概念

16.3 OpenSSH - SSHプロトコルの実装

OpenSSHは、Oracle Linuxで使用可能なセキュア・シェル(SSH)プロトコルの実装であり、一般にLinuxおよびUnixベースのオペレーティング・システムで使用できます。

セキュア・シェル・デーモン・アプリケーション(sshd)は、受信SSH接続リクエストをリスニングするSSHサーバーで実行しているOpenSSHサービスです。通常、sshdはrootユーザーとして実行されます。sshは、SSH接続の開始に使用されるOpenSSHクライアント・ソフトウェアです。クライアントとサーバーの両方の実装に、独自の構成ファイルがあります。

OpenSSHは、公開キー認証をサポートしています。SSHユーザー・キー・ペアの作成が必要になります。秘密キーは、SSHクライアント・ホスト上にあり、安全の確保が必要です。通常、公開キーはSSHサーバーにあるホスト・ユーザーのauthorized_keysファイルに追加されます。クライアントは、SSHサーバーのそのホスト・ユーザーとして接続します。それ以外のホスト・ユーザーとしての接続は拒否されます。ただし、そのホスト・ユーザーのauthorized_keysファイルに、クライアントの公開キーも存在している場合を除きます。通常、認可キーのファイルは~/.ssh/authorized_keysファイルとして格納されます。公開キーは、authorized_keysファイル内ではSSH形式になっています。

図16-2 Open SSHの設定


図16-2の説明が続きます
「図16-2 Open SSHの設定」の説明

SSHクライアントJohnのSSHユーザー・キーは、Johnまたは管理者が作成します。キーはSSHクライアント・ホスト上に格納されます。Johnの公開キーは、SSHサーバーphoenix上のoracleユーザーのauthorized_keysファイルに追加されます。Johnは、oracleとしてSSHサーバーphoenixへの接続を開始できるようになりました。ただし、phoenix上のopcなど、他のユーザーとしての接続は、opcのauthorized_keysファイルにJohnの公開キーが存在しないため拒否されます。

クライアントは、oracleとしてphoenixにログインすると、authorized_keysファイルを変更して他のクライアントにアクセス権を付与することや既存のクライアントからアクセス権を取り消すことができる場合があります。

親トピック: SSHキー管理の概念

16.4 SSH公開キー認証の課題

次の各項では、SSH公開キー認証で直面する課題について説明します。

  • 制限された分散型アクセス制御
    一般的な公開キー認証の設定では、セキュア・シェル(SSH)サーバー管理者またはSSHサーバー・ホスト・ユーザーが、SSHサーバー・ホスト・ユーザーのauthorized_keysファイルに公開キーを追加します。
  • クライアント・キー管理
    セキュア・シェル(SSH)は、操作と管理の目的でリモート・ホストにアクセスするツールであるため、組織内の何百人ものユーザーがSSHを使用することになります。
  • ガバナンス
    SSHキーは組織全体に散在するため、エンタープライズ全体で一律のキー管理ポリシーを施行して、キー管理のベスト・プラクティスに従うことが困難になります。
  • レポートの欠落
    セキュア・シェル(SSH)サーバーへの分散アクセスでは、誰(SSHクライアント・ユーザー)が何(SSHサーバー)にアクセスできるかについてのレコードがありません。SSH構成のエンタープライズ全体のビューは存在しません。

親トピック: SSHキー管理の概念

16.4.1 制限された分散型アクセス制御

一般的な公開キー認証の設定では、セキュア・シェル(SSH)サーバー管理者またはSSHサーバー・ホスト・ユーザーが、SSHサーバー・ホスト・ユーザーのauthorized_keysファイルに公開キーを追加します。

セキュア・シェル(SSH)サーバー・ホスト・ユーザーは、通常、自分専用のauthorized_keysファイルにアクセスできます。SSHサーバー・ホスト・ユーザーとしてSSHサーバーにログインする権限は、次によって制御されます:
  1. SSHサーバー自体、および
  2. SSHサーバー・ホスト・ユーザーまたはSSHサーバー管理者。

認可制御はSSHサーバーの複数の主体が担当するため、一貫性がある一律のアクセス制御が存在しません。

この問題は、複数のSSHクライアント・ユーザーがSSHサーバー・ホスト・ユーザーになる可能性があるためにさらに悪化します。SSHクライアント・ユーザーがSSHサーバー・ホスト・ユーザーとしてSSHサーバーに正常に接続すると、このユーザーはauthorized_keysファイルに別のSSHクライアント・ユーザーの公開キーを追加できるようになります。このようにSSHサーバー・ホスト・ユーザーとして操作しているクライアント・ユーザーによる制御されていないアクセス許可は、本質的に、特定のSSHクライアント・ユーザーにのみ認可を付与することを目的とした管理者アクセス認可を迂回するものです。

第二に、認可制御は各SSHサーバーで実施されるため、これらすべてのSSHサーバーのSSH管理者の関与が人為ミスにつながっています。異なる3人の管理者が異なる3つのSSHサーバーにキーを追加して、それらの3つすべてに単一のユーザー・アクセス権を付与することが必要になる場合があります。これは、認可されてからSSHサーバーで有効になるまでに時間のずれが生じるため、理想的とはいえません。さらに、分散型アプローチは時間がかかり、調整が必要であり、まだエラーが発生しやすいものです。

図16-3 localized-SSH-server-access


図16-3の説明が続きます
「図16-3 localized-SSH-server-access」の説明

最後に、分散型のアクセス制御アーキテクチャの特性として、独自のセキュリティ・リスクがあります。SSHサーバーへのアクセスが不要になったユーザーの公開キーは、該当するSSHサーバーから適時に削除する必要があります。ただし、分散型アクセス制御では、取消しプロセスに時間がかかることがあります。別の例として、SSHサーバー・ホスト・ユーザーがSSHサーバーへのアクセスをバンド外で付与した場合があります。この認可には記録も認識もないため、セキュリティ・リスクが高まります。

エンタープライズ設定では、複数の管理者が、ドメイン内にある数千のホストに対する何百人ものユーザーのアクセス権を付与または取り消します。この規模になると、アクセス制御アーキテクチャの分散化された性質はすぐに圧倒され、システムは一般的にエラーが発生しやすくなり、セキュリティ・リスクにさらされやすくなります。

親トピック: SSH公開キー認証の課題

16.4.2 クライアント・キー管理

セキュア・シェル(SSH)は、操作と管理の目的でリモート・ホストにアクセスするツールであるため、組織内の何百人ものユーザーがSSHを使用することになります。

また、セキュリティ向上のため、ユーザー認証の望ましい方法は、多くの場合、公開キー認証になります。セキュア・シェル(SSH)は、サーバー間の通信と操作に最適なツールでもあります。数百ものSSHクライアント・ユーザー、ユーザーおよびサーバーが同様に、それら固有のSSHキー・ペアを生成します。すべてのSSHクライアント・ユーザーが、各自のSSHキー・ペアを管理する必要があります。その結果として、キー・スプロールが異常に拡大し、組織全体のデプロイメントにセキュリティ上の弱点が必ず存在するようになります。

すべてのSSHクライアント・ユーザーが、各自の秘密キーを侵害から保護する必要があります。すべてのSSHクライアント・ユーザーが、各自のSSHキーのライフサイクル管理を実施する必要があります。SSHキー・ペアは定期的にローテーションする必要があります。SSHキーには有効期限がないため、これはさらに複雑になります。すべてのSSHクライアント・ユーザーが、各自の古いキー・ペアがSSHサーバーとSSHクライアント・ホストから削除されていることを確認する必要があります。SSHキーがエンタープライズ全体に散在していると、キーの適切なライフサイクル管理を実施することは困難な作業になります。

図16-4 Limited-SSH-User-Key-Management


図16-4の説明が続きます
「図16-4 Limited-SSH-User-Key-Management」の説明

親トピック: SSH公開キー認証の課題

16.4.3 ガバナンス

SSHキーは組織全体に散在するため、エンタープライズ全体で一律のキー管理ポリシーを施行して、キー管理のベスト・プラクティスに従うことが困難になります。

セキュア・シェル(SSH)クライアント・ユーザーは、異なるサイズのキーを作成できます。また、異なるSSHサーバーにアクセスするために異なるSSHキーを使用することもできます。これが望ましいこともありますが、必ずしもそうではありません。SSHサーバーへのアクセス権を一時的に付与するポリシーや、従業員が休暇中の場合などにSSHサーバー・マシンから一時的にアクセス権を削除するポリシーを実施することは非常に困難です。一元的な制御なしでは、すべてのSSHクライアント・ユーザーにガバナンスの実施を依頼することになりますが、これはエラーが発生しやすく、大規模に実現できる可能性はほとんどありません。

親トピック: SSH公開キー認証の課題

16.4.4 レポートの欠落

セキュア・シェル(SSH)サーバーへの分散アクセスでは、誰(SSHクライアント・ユーザー)が何(SSHサーバー)にアクセスできるかについてのレコードがありません。SSH構成のエンタープライズ全体のビューは存在しません。

レコードは、SSHクライアント・ユーザーに対するアクセス権の取消しや付与の際に、またエンタープライズ内で認可を監査するときに不可欠なものです。

SSHキー管理に分散アプローチを使用していると、SSHキーの一元的なインベントリが存在しないことから、SSHクライアント・ユーザーが不必要なキーや複数のキーを使用しているかどうか、古いキーがパージされているかどうかを識別することが困難になります。それらのSSHキー・インベントリを完全に可視化しないと、組織は弱いリンクを特定して削除し、エンタープライズ全体で一律のポリシーを適用できません。

親トピック: SSH公開キー認証の課題

16.5 Oracle Key VaultによるSSHサーバーへのアクセスの一元的な制御

Oracle Key Vaultでは、セキュア・シェル(SSH)サーバーへのアクセスを一元的に管理できます。一元化されたアクセス制御により、セキュリティが向上し、脅威への迅速な対応が可能になり、人為ミスが少なくなり、大規模な認可管理が簡略化されます。

AuthorizedKeysCommand

OpenSSHデーモンsshd_configの構成ファイルには、AuthorizedKeysCommandキーワードが含まれています。このキーワードでは、SSHクライアント・ユーザーの公開キーをルックアップするために使用できるプログラムを指定します。構成により、このプログラムには、SSHサーバー・ホストにログインするサーバー・ホスト・ユーザー(つまり、SSHサーバー・ホスト・ユーザー)と、SSHクライアント・ユーザーの公開キーも提供できます。このプログラムは、認可された公開キーをSSH形式で標準出力に出力します。AuthorizedKeysCommandキーワードは、公開キー認証にのみ適用されます。Oracle Key Vaultには、$OKV_HOME/binにあるスクリプト(okv_ssh_ep_lookup_authorized_keys.sh)が付属しています。このスクリプトは、Oracle Key Vaultで公開キーをルックアップするために使用されます。

SSHサーバー・ホスト・ユーザー

これは、SSHクライアント・ユーザーがSSHサーバー・ホストとしてログインするために使用する、SSHサーバー上のオペレーティング・システム・ユーザーです。

SSHサーバー・エンドポイント

リリース21.7のOracle Key Vaultには、新しいエンドポイント・タイプの「SSH Server」が追加されています。「SSH Server」エンドポイント・タイプは、SSHサーバーにデプロイする必要があります。SSH Serverエンドポイント・ソフトウェアには、Oracle Key Vaultサーバーで認可された公開キーをルックアップするスクリプトが含まれています。SSHデーモンのAuthorizedKeysCommandキーワードでは、このokv_ssh_ep_lookup_authorized_keys.shスクリプトを起動するように構成する必要があります。SSHサーバー・エンドポイントには、SSHサーバー・ホスト名が関連付けられています。SSHサーバー・エンドポイントをデプロイできるプラットフォームについては、「SSHサーバーおよびクライアント・エンドポイントでサポートされているプラットフォーム」を参照してください。

これらは、このリリースでの、SSHサーバー・エンドポイントでサポートされているプラットフォームです。
  • Oracle Linux (7、8)
  • Oracle Solaris SPARC 11.4
  • Oracle Solaris X64 11.4
  • HP-UX (IA) 11.31

SSHサーバー・ウォレット

Oracle Key Vaultリリース21.7以降では、異なるタイプのウォレットを作成できます:
  • SSHサーバー・ウォレット
    • このウォレットには、SSHサーバー・ホスト・ユーザーが関連付けられています。
    • SSHサーバー・ホスト・ユーザーとしてSSHサーバーにアクセスすることを許可された公開キーのみが含まれます。
  • 汎用ウォレット
    • このタイプは、すべての既存のウォレットをカバーします
    • TDEキー、シークレット、不透明オブジェクトなどを格納できます。
SSHサーバー・エンドポイントに使用するウォレットのタイプは、SSH Serverにする必要があります。SSHサーバー・ウォレットに格納できるのは公開キーのみで、SSHサーバー・ウォレットへのアクセス権を付与できるのはSSHサーバー・エンドポイントのみです。SSHサーバー・ウォレットには、SSHサーバー・ホスト・ユーザーが関連付けられています。

SSHサーバー・マッピング・ファイル

SSHサーバー・エンドポイントでは、SSHサーバー・マッピング・ファイルを設定する必要があります。これは、okv_ssh_ep_lookup_authorized_keys.shスクリプト用の構成ファイルです。このファイルには、SSHサーバー・ホスト・ユーザーからそれに対応するSSHサーバー・ウォレットへのマッピングが含まれています。SSHサーバー・ホスト・ユーザーごとに、対応するSSHウォレットがOracle Key Vaultで設定されている必要があります。このマッピングは、SSHクライアント・ユーザーがSSHサーバーでSSHサーバー・ホスト・ユーザーとして操作することを認可するために、SSHウォレット内の所定の公開キーを使用できるかどうかの判別に役立ちます。 
# Configuration file for Oracle Key Vault SSH server endpoints
# [ <SSH server host user> ]
# ssh_server_wallet= <SSH wallet>

[ opc ]
ssh_server_wallet=opc_ssh_wallet

[ oracle ]
ssh_server_wallet=oracle_ssh_wallet

SSHサーバー・エンドポイント・ルックアップ・スクリプト

OpenSSHデーモンはrootユーザーとして実行する必要があり、SSHエンドポイントはrootユーザーとしてデプロイする必要があります。OpenSSHデーモンは、Oracle Key Vaultのokv_ssh_ep_lookup_authorized_keys.shスクリプトを実行するように、AuthorizedKeysCommandキーワードを使用して構成する必要があります。SSHエンドポイントは、okv_ssh_ep_lookup_authorized_keys.shスクリプトを使用して、Oracle Key Vaultへの安全な接続を設定し、エンドポイントが公開キーにアクセスできることを確認します。この目的のために、OpenSSHデーモンは、SSHサーバー・ホスト・ユーザーと、SSHクライアント・ユーザーの公開キーをスクリプトに提供するように構成されます。このスクリプトは、SSHサーバー・ホスト・ユーザーを使用して、SSHサーバー・マッピング・ファイルに格納されている対応するSSHウォレット・マッピングをルックアップします。マッピング・ファイルからSSHウォレットが特定されると、このスクリプトは、そのウォレットをOracle Key Vaultで見つけてオープンし、SSHクライアント・ユーザーの公開キーをルックアップします。公開キーがSSHエンドポイントにアクセスできる場合、SSHクライアント・ユーザーはSSH認証の続行を認可されます。SSHクライアント・ユーザーによって提示された公開キーが、マップされたSSHウォレットで使用できない場合、SSHクライアント・ソフトウェアは、SSHユーザーの別の公開キー(ある場合)を使用して操作を再試行します。SSHウォレット内に一致する公開キーが見つからない場合、接続は終了します。

  • デプロイメント
    セキュア・シェル(SSH)ウォレットは、SSHサーバーでSSHサーバー・ホスト・ユーザーの認可を一元的に管理する手段です。

親トピック: SSHキー管理の概念

16.5.1 デプロイメント

セキュア・シェル(SSH)ウォレットは、SSHサーバーでSSHサーバー・ホスト・ユーザーの認可を一元的に管理する手段です。

SSHクライアント・ユーザーの公開キーがSSHサーバー・ホスト・ユーザーのSSHサーバー・ウォレット内にあれば、そのSSHサーバー・ホスト・ユーザーとしてクライアントはSSHサーバーにアクセスすることを認可されます。管理者は、SSHクライアント・ユーザーの公開キーをSSHウォレット内で追加または削除することで、SSHクライアント・ユーザーのSSHサーバーへのアクセス権を付与または取り消すことができます。SSHエンドポイントは、SSHクライアント・ユーザーにアクセス権が付与されているSSHサーバーを識別します。SSHクライアント・ユーザーは複数のSSHサーバー・ホスト・ユーザーへのアクセスをリクエストできるため、SSHエンドポイントには複数のSSHウォレットへのアクセスが必要になることがあります。

図で、SSHサーバー・アクセスがOracle Key Vaultで一元的に管理される、一般的な設定を示します。

SSHクライアント・ユーザーJohnは、SSHサーバー・ホスト・ユーザーoracleとして、SSHサーバーphoenixにログインしようとしています。phoenixはSSHエンドポイントとともに設定されており、OpenSSHデーモンは、ルックアップ・スクリプト(okv_ssh_ep_lookup_authorzied_keys)を使用してOracle Key Vault内の公開キーをチェックするように設定されています。phoenix上のOSユーザーoracleの場合、SSHサーバー・マッピング・ファイルにより、phoenixのOSユーザーoracleがOracle Key Vault内のoracle_ssh_walletにマップされます。SSHウォレット(oracle_ssh_wallet)はOracle Key Vault内に作成され、phoenix上のSSHエンドポイントにはoracle_ssh_walletへの読取りアクセス権が付与されます。

Johnがユーザーoracleとしてphoenixにログインしようとすると、SSHデーモンにより、ユーザーoracle (Johnはこのユーザーとしてルックアップ・スクリプトへのログインを試みている)とともにJohnから受け取った公開キーが渡されます。ルックアップ・スクリプトで、SSHウォレット(この場合は、oracle_ssh_wallet)へのoracleのマッピングがチェックされます。次に、ルックアップ・スクリプトで、Johnの公開キーがoracle_ssh_walletに存在するかどうかがチェックされます。ない場合は、クライアントで、次の公開鍵(ある場合)を使用して再試行されます。oracle_ssh_walletに公開キーが1つもない場合は、クライアント接続が拒否され、そうでない場合は、SSHユーザー認証がさらに続行されます。Johnが最終的にoracleとしてphoenixにログインできるかどうかは、対応する秘密キーがJohnにあるかどうかと、phoenixでどのようにSSHユーザー認証が設定されているかで異なります。

図16-5 Centralized-SSH-Server-Access


図16-5の説明が続きます
「図16-5 Centralized-SSH-Server-Access」の説明

SSHウォレット、SSHエンドポイントおよびSSHサーバー・ホスト・ユーザーからSSHウォレットへのマッピングは、SSHサーバー・ホスト・ユーザーとしてのSSHサーバーの認可を一元的に管理するように設定する必要があります。SSHデーモンは、rootユーザーとしてデプロイする必要があります。SSHエンドポイントは、rootユーザーとしてデプロイされます。sshd_configファイルのAuthorizedKeysCommandキーワード引数は、SSHサーバー・エンドポイント・ルックアップ・スクリプトを指すように更新する必要があります。SSHクライアント・ユーザーがログインするSSHサーバー・ホスト・ユーザーごとに、SSHサーバー・マッピング・ファイルにマッピング・エントリが存在している必要があります。複数のSSHサーバーが同じSSHサーバー・ウォレットを共有して、それらのサーバーで対応するSSHホスト・ユーザーの認可を管理できます。これは、同じSSHクライアント・ユーザーのセットが、それらのSSHサーバーのいずれかでホスト・ユーザーとしてログインする権限があることを意味します。

SSHエンドポイントはOpenSSHデーモンと連動することで、受信接続が認可されているかどうかを検証します。認可は、SSHクライアントが提示した公開キーがSSHウォレットに存在するかどうかに依存します。1人以上のSSHクライアント・ユーザーの公開キーは、Oracle Key Vaultで一元的に複数のSSHサーバーのホスト・ユーザーのSSHウォレットに追加または削除できるため、SSHサーバーの集中アクセスが可能になります。

親トピック: Oracle Key VaultによるSSHサーバーへのアクセスの一元的な制御

16.5.1.1 ルート・ユーザーに制限したアクセス制御

SSHサーバーの認可が一元的に管理されていても、OpenSSHデーモン構成によって、SSHクライアント・ユーザーはSSHサーバーにログインできる可能性が残ります。

SSHクライアント・ユーザーのSSHサーバーへの最初のログインはOracle Key Vaultで一元的に制御されますが、クライアント・ユーザーがホスト・ユーザーとしてSSHサーバーにログインすると、このユーザーは別のSSHクライアント・ユーザーの公開キーをホスト・ユーザーの認可キー・ファイルに追加できるため、Oracle Key Vaultの一元アクセス制御を迂回することになります。このため、SSHデーモンは、通常のSSHサーバー・ホスト・ユーザーにはauthorized_keysファイルのサポートを許可しないように構成して、一元的なアクセス管理を実施する必要があります。SSHがSSHサーバー・ホスト管理の主な手段である場合、authorized_keysファイルは、緊急時にシステムを回復できるようにするためのrootユーザーのフォールバック・オプションとして保持することをお薦めします。

親トピック: デプロイメント

16.6 Oracle Key VaultによるSSHユーザー・キーの管理

Oracle Key Vaultでは、SSHクライアント・ユーザーのセキュア・シェル(SSH)キー・ペアを一元的に管理できます。

一元化されたキー管理は、SSHキーに1つのリポジトリという構造化と組織化をもたらすだけでなく、キーのガバナンス、キーのライフサイクル管理、ローテーションや失効などのキー操作を実施することでセキュリティを向上させます。

  • デプロイメント
    Oracle Key Vaultは、OpenSSHとの統合によって、Oracle Key VaultからのSSHユーザー・キーを使用してSSH認証をサポートします。Oracle Key Vaultには、OpenSSHクライアントがOracle Key Vaultに格納されているSSHキーを使用してSSH認証ステップを実行するために利用できる、PKCS#11ライブラリが用意されています。

親トピック: SSHキー管理の概念

16.6.1 デプロイメント

Oracle Key Vaultは、OpenSSHとの統合によって、Oracle Key VaultからのSSHユーザー・キーを使用してSSH認証をサポートします。Oracle Key Vaultには、OpenSSHクライアントがOracle Key Vaultに格納されているSSHキーを使用してSSH認証ステップを実行するために利用できる、PKCS#11ライブラリが用意されています。

どのOracle Key Vaultエンドポイントでも、SSHキー・ペアをOracle Key Vaultにアップロードできます。管理とアクセス制御の向上のために、SSHキーのペアはウォレットにアップロードする必要があります。Oracle Key Vault 21.7以降、ユーザーはOracle Key VaultでSSHキーを作成することもできます。すべてのOracle Key Vaultエンドポイント・タイプに、Oracle Key VaultのPKCS#11ライブラリが含まれています。そのため、どのOracle Key VaultエンドポイントもSSHクライアント・ユーザーとして機能できます。「Oracle Key Vault仮想ウォレットとセキュリティ・オブジェクトの管理」の「キーの作成」を参照してください。

Oracle Key Vaultが操作できるSSHクライアント・ソフトウェアは、OpenSSHに限定されます。Oracle Key Vaultエンドポイントは、SSHクライアントにデプロイする必要があります。エンドポイントのPKCS#11ライブラリは、OpenSSHクライアント・プログラムによってロードされます。PKCS#11ライブラリはOracle Key Vaultと通信して、SSHクライアント・プログラムがリクエストしたSSH操作を実行します。その操作は、Oracle Key Vaultに格納されているSSHキーを使用して実行されます。

Oracle Key VaultにSSHキーがある場合、SSHクライアント・ユーザーは次のコマンドを使用して接続を設定します: 
 ssh -I $OKV_HOME/lib/liborapkcs.so <ssh server host user>@<ssh server>

Oracle Key VaultのPKCS#11ライブラリは、-Iオプションを使用することで、OpenSSHクライアント・ソフトウェアによってロードされます。その他の関連するOpenSSHクライアント・ソフトウェアは、いつでも使用できます。ユーザーは、ssh-agentを使用して接続PINをキャッシュすることもできます。エンドポイントが自動ログイン設定でデプロイされている場合、接続PINはNULLになります(Oracle Linux 8)。それ以外の場合、接続PINは、エンドポイントのデプロイ時に使用したエンドポイント・パスワードです(Oracle Linux 9)。

SSH秘密キーの抽出可能属性をFALSEに設定したままにして、SSH秘密キーがOracle Key Vaultクラスタの境界から離れないようにすることをお薦めします。エンドポイントはSSHクライアント・ホストにデプロイされます。SSHクライアント・エンドポイントには、このウォレットに対する読取り権限と変更権限が必要です。SSHクライアント・ユーザーがSSHキーを登録する必要がある場合は、ウォレット管理権限が必要です。SSHエンドポイントには、SSHクライアント・ユーザーがOracle Key Vaultサーバーへの接続を設定する必要があるときにOpenSSHクライアント・ソフトウェアで使用されるPKCS#11ライブラリも含まれています。

Centralized-SSH-Key-Managementの図は、Oracle Key VaultでSSHキーを管理するための設定を示しています。SSHキーを格納し管理するために、SSHクライアント・ユーザーごとに汎用ウォレットを作成する必要があります。

図16-6 Centralized-SSH-User-Key-Management


図16-6の説明が続きます
「図16-6 Centralized-SSH-User-Key-Management」の説明

SSHキーをOracle Key Vaultに登録または作成すると、これらのキーのキー管理がより簡単になります。非アクティブ化日をこれらのキーに関連付けることができ、キーが期限切れになりローテーションが必要になると顧客に通知されます。SSHキーは定期的にローテーションできます。SSHキーが侵害された場合は、それらのキーをすぐに取り消すことができます。また、SSHクライアント・ユーザーのSSHキーをOracle Key Vaultに登録すると、余分な未使用のキーを簡単に特定し除去できるため、SSHユーザー・キーの整理と管理が合理化されます。さらに、管理者はSSHキーをキー・ライフサイクル管理の対象にできます。

Oracle Key VaultでSSHキーを管理すると、キーの組織化や管理が簡単になり、キー管理のベスト・プラクティスが実践されます。

親トピック: Oracle Key VaultによるSSHユーザー・キーの管理

16.7 Oracle Key VaultとSSHの統合

Oracle Key Vaultでは、セキュア・シェル(SSH)キーの管理に加えて、SSHサーバーへのアクセス制御も個別に実行できますが、SSHキーとSSHサーバーのアクセス制御の両方をOracle Key Vaultで一元的に管理することが理想的です。

  • Oracle Key VaultとSSHの統合について
    Oracle Key Vaultは、セキュア・シェル(SSH)秘密キーとSSH公開キーの両方を一元的に管理します。公開キーの管理によってエンタープライズ内のSSHサーバーのアクセス制御が可能になり、秘密キーの管理によってエンタープライズ全体のSSHキーのキー・ガバナンス、キー管理および組織化が実践されます。
  • SSH管理者によるSSHユーザー・キーとSSHサーバーへのアクセスの管理
    このモデルでは、セキュア・シェル(SSH)管理者は、エンタープライズ全体のSSHキーとSSHサーバーへのアクセスの管理を担当します。SSHクライアント・ユーザーは、SSH管理者が管理するキーをサブスクライブすることになります。
  • SSHクライアント・ユーザーによるSSHキーの管理とSSH管理者によるSSHサーバーへのアクセスの管理
    このモデルでは、SSH管理者はエンタープライズ全体のSSHサーバーへのアクセス制御のみを担当します。SSHクライアント・ユーザーは、自分でSSHユーザー・キーを所有して管理します。SSHクライアント・ユーザーがSSHユーザー・キーを所有して管理します。

親トピック: SSHキー管理の概念

16.7.1 Oracle Key VaultとSSHの統合について

Oracle Key Vaultは、セキュア・シェル(SSH)秘密キーとSSH公開キーの両方を一元的に管理します。公開キーの管理によってエンタープライズ内のSSHサーバーのアクセス制御が可能になり、秘密キーの管理によってエンタープライズ全体のSSHキーのキー・ガバナンス、キー管理および組織化が実践されます。

SSHキーの設定とSSHサーバーのアクセス制御の設定は、前のセクションで説明したとおりに実行できます。

次の図は、SSHキーおよびアクセス制御管理を示しています。Johnは、SSHサーバー・ホスト・ユーザーoracleとしてphoenixへの接続を開始します。

Johnが、SSHクライアント・エンドポイントのPKCS#11ライブラリを提供します。PKCS#11ライブラリでは、接続を設定するために使用できるすべての公開キーがフェッチされます。それらのキーは、接続が確立されるまで1つずつ試されます。SSHサーバーでは、Oracle Key Vaultのエンドポイント・ルックアップ・スクリプトによって、SSHサーバー上のSSHサーバー・ウォレット内の対応する公開キーが認可されているかどうかがチェックされます。認可されている場合、SSH認証プロセスで、一致した認可された公開キーの使用が続行されます。認可されていない場合は、接続の試行がブロックされます。

ノート:

SSHクライアントまたはSSHサーバーに、秘密キーと公開キーのフットプリントはありません。

図16-7 Centralized-SSH-Key-Management


図16-7の説明が続きます
「図16-7 Centralized-SSH-Key-Management」の説明

さらに、一元的にローテーションできるという利点も加わります。取消しにより、侵害されたキーがSSHクライアントで使用されることを防ぐだけでなく、SSHサーバーへのアクセスのブロックもできます。

Oracle Key Vaultでは、エンドポイントを一時的に中断することも、エンドポイントのウォレットへのアクセス権を削除することもできます。これらの対策のいずれかまたは両方を使用して、SSHサーバーのSSHクライアント・ユーザー・アクセスを中断できます。これは、SSHクライアント・ユーザーが休暇などで短い期間中はシステムにアクセスしないことがわかっていて、そのSSHクライアント・ユーザーのキーを使用したSSHサーバーの意図しない、偶発的または悪意のあるアクセスを防止する場合に役立ちます。

SSH管理者

SSH管理者は、SSHエンドポイントとSSHウォレットを所有するOracle Key Vaultユーザーですが、SSHユーザー・キーを管理する場合としない場合があります。一般に、SSH管理者は、1つ以上のSSHサーバーまたはSSH管理者のSSHドメインへのアクセスも制御します。

SSHユーザー・キーの管理とSSHサーバーへのアクセス制御には、2つのモデルがあります。一方では、SSH管理者が両方を管理します。もう一方では、SSHクライアント・ユーザーが自分のキーを管理して、SSH管理者がSSHサーバーへのアクセスを制御します

親トピック: Oracle Key VaultとSSHの統合

16.7.2 SSH管理によるSSHユーザー・キーとSSHサーバーへのアクセスの管理

このモデルでは、セキュア・シェル(SSH)管理者は、エンタープライズ全体のSSHキーとSSHサーバーへのアクセスの管理を担当します。SSHクライアント・ユーザーは、SSH管理者が管理するキーをサブスクライブすることになります。

SSH管理者には、SSHサーバー・ウォレットとSSHクライアント・ユーザーのSSHキーを格納する汎用ウォレットの読取り、変更および管理を実施するための権限があります。一般に管理者は、これらのウォレットを作成し、SSHクライアント・ユーザーとSSHサーバー・エンドポイントに必要な権限を付与します。

SSH管理者は、SSHサーバー・エンドポイントを作成して所有します。また、SSH管理者は、SSHサーバーへのSSHサーバー・エンドポイント・ソフトウェアのデプロイとOpenSSHデーモン構成の変更も担当します。

SSHユーザー・キー管理

SSH管理者は、SSHキー・ペアを作成するか、SSHキー・ペアをOracle Key Vaultに登録します。キーは、組織のポリシーに応じて特定のキー・サイズで作成します。SSH管理者は、SSHキー・ペアに非アクティブ化の日付を関連付けることもできます。管理者には、キーが期限切れになるときにキーをローテーションできるように通知が送信されます。

SSH管理者は、SSHクライアント・ユーザーの汎用ウォレットを作成して、SSHクライアント・ユーザーが使用するエンドポイントにウォレットの読取りアクセス権を付与します。SSH管理者は、新しく作成または登録したSSHキー・ペアをSSHクライアント・ユーザーの汎用ウォレットに追加します。その他のユーザーやエンドポイントは、このSSHキー・ペア(特にSSH秘密キー)にアクセスする必要はありません。

アクセス制御

SSH管理者は、SSHサーバーのSSHウォレットにSSHクライアント・ユーザーの公開キーを追加して、そのSSHサーバーへのアクセス権をSSHクライアント・ユーザーに付与します。SSH管理者は、SSHクライアント・ユーザーの公開キーをSSHウォレットから削除して、SSHサーバーに対するSSHクライアント・ユーザーへのアクセス権を取消しできます。

SSH管理者は、SSH秘密キーからSSHクライアント・ユーザーのアクセス権を削除して、SSHクライアント・ユーザーがSSHドメイン内のどのSSHサーバーにもアクセスできないようにすることもできます。このアプローチは、従業員が組織を辞めて、すべてのSSHエンドポイントからすぐにアクセス権を取り消す必要がある場合などに採用します。

親トピック: Oracle Key VaultとSSHの統合

16.7.3 SSHクライアント・ユーザーによるSSHキーの管理とSSH管理者によるSSHサーバーへのアクセスの管理

このモデルでは、SSH管理者はエンタープライズ全体のSSHサーバーへのアクセス制御のみを担当します。SSHクライアント・ユーザーは、自分でSSHユーザー・キーを所有して管理します。SSHクライアント・ユーザーがSSHユーザー・キーを所有して管理します。

SSHクライアント・ユーザーは、SSHクライアント・ユーザーのSSH公開キーと秘密キーのペアを保持する汎用ウォレット、およびSSH公開キーのみを保持するSSHサーバー・ウォレットという、2つのウォレットを作成します。SSHクライアント・ユーザー以外には、最初のウォレットへのアクセス権はありません。SSH管理者には、2番目のウォレット(SSHクライアント・ユーザーの公開キー・ウォレット)への読取りアクセス権が付与されます。

SSHクライアント・ユーザーは、Oracle Key VaultでSSHキー・ペアの作成または登録を実行して、それを汎用ウォレットに格納します。SSH公開キーのみが、SSHクライアント・ユーザーの公開キー・ウォレットに格納されます。SSHクライアント・ユーザーは、SSHクライアント・ユーザー・エンドポイントも所有して管理します。このモデルのSSHキー管理は、SSHクライアント・ユーザーが担当します。

SSH管理者は、SSHサーバー・エンドポイントとSSHサーバー・ウォレットを作成して所有します。SSH管理者は、SSHサーバーへのSSHサーバー・エンドポイント・ソフトウェアのデプロイと、OpenSSHデーモン構成の変更を担当します。

SSHユーザー・キー管理

SSHクライアント・ユーザーは、SSHキー・ペアを作成するか、SSHキー・ペアをOracle Key Vaultに登録します。キーは、組織のポリシーに応じて特定のキー・サイズで作成する必要があります。SSHクライアント・ユーザーは、SSHキー・ペアに非アクティブ化の日付を関連付けることもできます。キーが期限切れになると、SSHユーザーとOracle Key Vaultキー管理者に通知が送信されます。SSHキー管理者は、SSHユーザーが電子メール・アラートを受信するように設定していない場合に、キーが期限切れになっていることをSSHユーザーに通知することもできます。SSHクライアント・ユーザーは、SSHキーをローテーションします。新しいSSH公開キーは、それまでのSSH公開キーと同じ方法でSSH管理者が認可する必要があります。

SSHクライアント・ユーザーのみが、SSH公開キーと秘密キーにアクセスできます。SSH管理者は、SSHクライアント・ユーザーによるSSHキーへのアクセスを拒否できません。

アクセス制御

SSH管理者は、SSHクライアント・ユーザーの公開キー・ウォレットからSSHサーバーのSSHウォレットにSSHクライアント・ユーザーの公開キーを追加して、そのSSHサーバーへのアクセス権をSSHクライアント・ユーザーに付与します。SSH管理者は、SSHクライアント・ユーザーの公開キーをSSHウォレットから削除して、SSHサーバーに対するSSHクライアント・ユーザーへのアクセス権を取消しできます。

親トピック: Oracle Key VaultとSSHの統合

16.8 SSHサーバーおよびクライアント・エンドポイントでサポートされているプラットフォーム

Oracleでは、SSHサーバーおよびクライアント・エンドポイントで64ビットのプラットフォームがサポートされています。

これらは、このリリースでの、SSHサーバー・エンドポイントでサポートされているプラットフォームです。
  • Oracle Linux (7, 8, 9)
  • Oracle Solaris SPARC 11.4
  • Oracle Solaris X64 11.4
  • HP-UX (IA) 11.31
  • AIX 7.3

    ノート:

    SSHサーバーでは、OpenSSH 8以降が使用されている必要があります。
これらは、このリリースでの、SSHクライアント・エンドポイントでサポートされているプラットフォームです。
  • Oracle Linux (8、9)
  • Oracle Solaris SPARC 11.4
  • Oracle Solaris X64 11.4

ノート:

OpenSSHは、パスワードを必要としないエンドポイントの場合はバージョン7.2p1以上、パスワードが必要なエンドポイントの場合はバージョン8.1p1である必要があります。

親トピック: SSHキー管理の概念