twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux Jp チュートリアル Linuxで暗号鍵を管理する

Linuxで暗号鍵を管理する

原文は 2015 年 7 月 2 日に掲載されました。
 
key management diagram
SSH 用の暗号鍵を格納しておいたり、パスワードを覚えておくことは大変です。しかし、悪意のハッカーや侵害行為が蔓延している世界では基本的なセキュリティの備えが大事です。一般ユーザーの大半にとって、つまるところパスワードを記憶することであり、パスワードを覚えてくれるプログラムを探すことになります。IT 分野で仕事をしている我々は、より高いレベルが必要です。パスワードだけではなく、SSH 用キーも扱う必要があります。
 
次のような状況を考えてみましょう。クラウド上に git リポジトリを扱うサーバーを持っています。作業するためのコンピューターを数台持っています。各コンピューターから、サーバーにプルしたりプッシュしたりします。git は SSH を使うように設定しています。git が SSH を使う場合、SSH コマンドでサーバーのコマンド ラインを実行する時と同じ方法を用います。すべてを設定するために、.ssh ディレクトリ内に設定ファイル config を用意しました。そのファイルには、サーバー名、ホスト名、ログイン ユーザー、およびキー ファイルのパス名称を入れる Host 項目が記入されています。以下の行を実行することで、この設定ファイルが正しいか確認できます。
ssh gitserver

サーバーの bash shell が起動します。格納されたキーでログインできるように、同じエントリを git が使用するように設定します。1 つだけ問題があります。各コンピューターからサーバーにログインするには、キー ファイルが必要です。つまり、キー ファイルがいたるところに必要です。このコンピューター上に複数のキーがあります。他のコンピューターにも、同じようにキーがあります。同じように、ユーザーは毎日たくさんのパスワードを使っています。IT に携わる人間として、この状況を終わりにしましょう。

明確にする

キーを管理するプログラムについて語る前に、キーの扱い方について基本的な考察をして、もう少し状況を明確にしましょう。まず最初に、パブリック キーとプライベート キーの扱われ方を考えます。次のことはわかっています。
 
1. パブリック キーとプライベート キーの違い
 
2. パブリック キーからプライベート キーを生成できないが、その逆は可能
 
3. authorized_keys ファイルの目的と使用方法
 
4. authorized_key ファイルにパブリック キーを格納しているサーバーにログインする際のプライベート キーの役割
 
例です。Amazon web Service にクラウド サーバーがあります。サーバーに接続するときに使用する SSH キーを用意します。キーには、プライベートとパブリックがあります。サーバーをセキュアに保つために、プライベート キーをサーバーに、パブリック キーを手元に置くのが良いように見えます。つまり、サーバーが他からアクセスできるようにはしたくないわけです。でも、これは逆です。
 
パブリック キーを AWS サーバーに置き、プライベート キーはログインする時に使用します。上図にあるように、プライベート キーを保護するためにサーバーではなく手元に置きます。
理由です。:他者がパブリック キーを入手しても、プライベート キーがないため、サーバーにログインすることはできません。さらに、他者がサーバーに侵入しても、パブリック キーしか見つけることはできません。パブリック キーからプライベート キーは生成できません。他のサーバーで同じキーを利用していても、それらに侵入することはできません。
 
ですから、SSH でログインするサーバーにパブリック キーを置くのです。プライベート キーは手元に置いておきます。プライベート キーを外部に見せないでください。
 
まだ、問題があります。git サーバーについて考えてみましょう。いくつか決めることがあります。別の場所にある開発サーバーにログインすることがあります。開発サーバーから git サーバーにログインする必要があります。どうやればよいでしょうか。プライベート キーを使います。ここが問題です。この方法だと、別の場所にあるサーバーにプライベート キーを置く危険性があります。
さらに、複数のサーバーに同一キーでログインするとします。1 個のプライベート キーを侵入者に盗まれると、サーバーのネットワークに完全にアクセスされてしまいます。
 
さらにもう 1 つ問題があります。同じキーを他のサーバーに使うべきでしょうか。これは、先に述べたように危険です。
混乱するようなことですが、単純な解決案があります。
 
(サーバーへのログイン以外に、キーを使う場面はいろいろあります。しかし、ここではキーを扱う場合に直面する問題を紹介するためのシナリオを使いました。)

パスフレーズについて

キーを生成する時に、プライベート キーと一緒に使用するパス フレーズを設定するか問われます。プライベート キー ファイルは、パスフレーズで暗号化されます。もしサーバーにパブリック キーを格納し、プライベート キーをログインに使用する場合、パスフレーズの入力を求められます。パスフレーズなしではキーを利用できません。パスフレーズなしでもキーを構成できます。サーバーにログインするときにキー ファイルを使うだけです。
 
パスフレーズを使わない方法は、一般的に簡単です。しかし、いろいろな場面で、パスフレーズを使うことを強く勧めます。プライベート キー ファイルが盗まれた場合、パスフレーズなしでは使うことはできません。攻撃者がパスフレーズを見つけ出すまでに、サーバーのパブリック キーを削除できます。システムを保護できます。パスフレーズを使う別の理由があります。しかし、これはさまざまな状況の中で、私に適合するのは 1 つですが (Android タブレットで VNC を使う場合です。タブレットにはプライベート キーが格納されています。タブレットが盗まれたら、サーバーのパブリック キーを無効にし、パブリック キーを使えなくします)。しかしログインするサーバーにそれほど重要なデータがなさそうであれば、使わないこともあります。場合によります。

サーバー

サーバーの基本デザインが、キー管理に大きな影響を与えます。たとえば、複数ユーザーがログインする場合、各ユーザーに個別キーを与えるか、決める必要があります。(一般的に、そうすべきです。プライベート キーを共有してはなりません。そうすれば、誰かが仕事を辞めたりキーを失くしたりした時は、全員に新しいキーを生成する代わりに、該当するキーを無効にします。共有すると、他人としてログインできてしまいます。問題ですね。)また、サーバーの割り当て方法が問題となります。Puppet のようなツールを使って割り当てをしますか? 自分のイメージをベースに複数のサーバー イメージを作成しますか? サーバーを複製する時、各サーバーに同じキーを配布しますか? 他のクラウド サーバー ソフトウェアを使うと、希望どおりに構成することができます。各サーバーに同一のキーを配布することも、各々に新しいキーを配布することもできます。
 
複製されたサーバーを提供する場合、同じようなサーバーに異なるキーでログインすることは、ユーザーを混乱させます。一方、各サーバーが同じキーを持つことは、セキュリティ リスクとなります。さらに、キーをログイン以外に使用する場合(たとえば、暗号ドライブのマウント)、複数の場所で 1 つのキーが必要になります。もちろん、複数サーバーで 1 つのキーを使用する必要があるかどうかを決定するのは皆さんです。利点、欠点があるので、皆さんが自分にあったものを決めるのです。
 
状況を整理すると次のようになります。
 
- ログインするサーバーが複数ある。
 
- 各サーバーにユーザーが複数いて、それぞれキーを持っている。
 
- 各ユーザーが各サーバー ログイン用にキーを持っている
 
(キーを他の状況で使っている場合、基本的な考えは同じです。キーの使い方、キーの数、キーの共有方法、そして、プライベート キーとパブリック キーの扱い方です。)

安全確保方法

自分のサーバーの基本とそれぞれの状況を押さえて、キー管理プランを作成します。それにより、キーの配布方法と管理方法を明確にします。たとえば、先に書いたように、タブレットが盗まれたとします。タブレットを使ってサーバーにアクセスされる前に、サーバーのパブリック キーを無効にします。全体として、以下が許容できます。
 
1. モバイル デバイス中のプライベート キーは問題ありませんが、パスフレーズを設定すること。
 
2. サーバーのパブリック キーを急いで無効にする方法を用意すること。
 
状況によっては、ログインするシステムにパスフレーズを使いたくないと決めたとします。開発者が日に何度もログインするテスト マシンの場合などです。その場合は、ルールを少しいじります。モバイル デバイスからログインしないようなルールにするのです。つまり、状況に応じたプロトコルにします。1 つだけに限定しないことです。

ソフトウェア

ソフトウェアに関して言えば、プライベート キーの格納と管理ができる質の良いソフトウェアは多くありません。でも、あるでしょうか。考えてみてください。サーバー用のキーをすべて格納できるソフトウェアがあって、パスワードだけでロックできたとしましょう。本当にセキュアでしょうか。また、SSH で簡単にアクセスできるようにハード ドライブにプライベート キーを格納されているとしたら、キー管理ソフトウェアは、本当にキーを保護できるのでしょうか。
 
しかし、基盤を整備し、パブリック キーの生成と管理を行うためのソリューションなら、いくつかあります。Puppet では、いくつかの方法でサーバーを管理するモジュールを作成できます。サーバーは動的に生成され、完全な複製である必要がないことが大事です。異なるサーバーで同じキーを利用しながら、異なる Puppet モジュールを利用する賢い方法があります。この方法が使えるかもしれないし、使えないかもしれません。
 
別の方法として、他の道具を使う手があります。Docker では異なる方法が使えます。これについては、"SSH と Docker に関する blog" に書かれています。
では、プライベート キーについては、どうでしょうか。検索をしても、先に私が述べたようにほとんど結果はありません。プライベート キーは手元のハード ドライブに格納されているし、管理プログラムはセキュリティを強化してくれません。しかしここでは、これを使ったキー管理方法を紹介しましょう。
 
最初に .ssh/config ファイルに複数の Host 項目を作成します。ログインするホスト用項目を 1 つ記載していますが、1 つのホストについて、複数の項目が必要な時があります。これは、複数のログイン (アカウント) を持っているからです。git サーバーに 2 つのアカウントを持っています。1 つは git そのもの用、他方は bash を使って仕事をするための一般的なアカウントです。git 用は、サーバー上で強い制限があります。リモートの開発マシンにある git 用のキーについて、前に記載したことを思い出してください。さて、これらのキーでサーバーにログインすることはできますが、アカウントは厳しく制限されています。
 
次に、これらのプライベート キーの大半には、パスフレーズを適用しています(何回もパスフレーズを打ち込む時には、ssh-agent を利用することを考えてください)。
 
3 番目に、他よりガードを厳しくしたいサーバーがいくつかあるのです。それは、ホストの項目に入れたくありません。これは、もっとソーシャル エンジニアリングの観点から考えるべきものです。なぜなら、キー ファイルは、依然として存在し、侵入者がファイルを探し出し、マシンを特定することに時間が必要だからです。このようなときは、長いコマンドでも ssh コマンドを手で入力します (そんなに悪いことではありません)。
 
プライベート キーの管理には、特別なソフトウェアは使用していません。

すべてを解決する解はない

linux.com で、キー管理に関する良いソフトウェアがないかの質問を受けます。しかしちょっと待ってください。もう一度考えてみましょう。つまり、すべてを解決する解はないということです。あなたの質問は、あなたの状況に応じたものです。キー ファイルを格納する場所を探しているのですか?  それとも、複数のユーザーと autorized_key ファイルに設定すべきそれぞれのパブリック キーを管理したいのですか? 
 
本チュートリアルを通して、これらの組み合わせ方の基本を説明しましたので、キー ファイルをどのように管理すべきかわかっていただければ幸いですが、探しているソフトウェアは (もし必要としているならば)、適切な質問をして初めて見つかるのです。
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ

  1. Today's Linux 2018/04/09 2018年 4月 08日
  2. Today's Linux 2018/04/11 2018年 4月 10日
  3. Today's Linux 2018/04/10 2018年 4月 09日
  4. Today's Linux 2018/04/16 2018年 4月 15日
  5. Today's Linux 2018/04/17 2018年 4月 17日

Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!