やっと、管理コンソールが表示されてセットアップだぁ!と思っている方もいるかもしれませんが、そこはあせらずもうちょっと我慢したほうが、後々楽になります。
Amazon EC2とその周辺のAmazon Web Service群を使うときに何かと認証とかKeyとか証明書という言葉がでてきます。 これを理解していないと、ここではいったいどのKeyのことを言っているのか分からず、先に進めないことがあるからです。
やっかいなのは、Amazon Web Serviceのアカウントは1つしかないにもかかわらず、そのアカウントを認証するために複数の方式があり、どれかを選べる場合もあれば、特定の1つの方式しかサポートしていない場合もあります。 セキュリティの度合いによって使い分けているといえば聞こえがいいのですが、正直な感想としてはただ統一できていないだけのように思えます。メイン画面 http://aws.amazon.com/jp のアカウントメニューを開いて、セキュリティ証明書の管理画面を見てください。なんともあやしげな物が出てきます。
では、その混沌とした認証環境を整理していきましょう。
- メールアドレス+パスワードの管理コンソールログオン認証
- Access Key(アクセスキー)+Secret Key(シークレットキー)による認証(またはアクセスキーのみ)
- X.509証明書による認証
- 生のままのKey Pair(Amazon EC2の一対の鍵)
これらの4つの認証が出てきます。しかもこれらはすべて1つのAmazon Web Serviceアカウントを表す認証IDです。 しかもKeyという単語がたくさん出てきて、Access KeyとSecret Keyのペアがあるのに、Key Pairという別のものがあります。 セキュリティの説明ページの中ではX.509証明書を使うことをおすすめしますなどと、書いてありますが実際には証明書が使えない場所が沢山あります。 場所によって臨機応変に理解して使い分けなければならないという事です。 画面上の表示では単語がごちゃ混ぜになって使ってあるため、どれを指しているのか知っている人でなければかなり混乱します。 逆に知っていればなんと言うことはありません。
セットアップを始める前に、どんな所で認証IDたちが使われるかを挙げておきましょう。
(中にはAmazon CloudFrontの一対の鍵というのを見つけた人もいるでしょう、さらに混乱してしまうので見なかったことにしましょう。)
AWS Management Consoleへのログオン [#y845bfc9]
これは一番分かりやすいですね。ここで使うのが「1.メールアドレス+パスワードの管理コンソールログオン認証」です。Webブラウザから管理画面を開くときに使うメールアドレス+パスワードで認証します。 途中でログオン状態がうまく保てなくなるとすぐにメールアドレス+パスワードを聞いてくるので、その時はああぁまただと思ってメールアドレス+パスワードを入れてください。 なにか新しい認証IDを聞いてきているわけではありません。
インスタンス起動時に指定するコネクション認証キー
Linuxだと分かりやすいのですが、EC2上で起動するLinuxへのログオンは必ずsshの証明書認証である必要があります。ここで使うのが「4.生のままのKey Pair(Amazon EC2の一対の鍵)」です。 EC2上で起動する仮想サーバーの実体の事をInstance(インスタンス)と呼びますが、このInstance起動時に、Amazon Web Serviceアカウント上のKey pairを使って、起動するInstanceのサーバー側の証明書を作ります。 ややこしいのですが、管理画面から最初にInstanceを起動するときにAmazon Web Serviceアカウント上にKey pairが無いと、その場でKey pairを生成する画面が出てきます。 サーバー証明書を生成するために必要なKey pairを生成する画面です。これが俗に言う公開鍵ペアです(正確には公開鍵秘密鍵ペア)。 一度作ったKey pairは絶対にとっておく必要があります。なぜならそれが無いとssh接続できないからです。
勘違いしやすいのは、起動するごとにKey pairを生成してしまおうとする事です。これは間違っています。 なぜなら、2台のサーバーを起動するとか、1台のサーバでも2度目の起動があるわけですが、Amazon Web Serviceアカウント上では1つのKey pairしか有効にならないので、毎回生成していると、毎回以前起動したサーバーへ接続できるキーペアーを失ってしまうわけです。 起動するたびにKey pairのダウンロードをしてsshに登録するという作業は現実的ではありません。
理解しやすい方法の1つとしては、最初にInstance起動画面でKey pairの生成だけを行い実際にはInstanceの起動をしないでしないでおきます。Key pairを生成してうまくダウンロードできたら、手元のsshクライアントを使用する管理PCにKey pairを保存しておきます。 そして実際にOSを起動するときは、Instance起動画面ではいつも、Your existing Key Pairを選んでInstanceの起動を行うことです。 この章の初めの記述を思い出してください。ここのKey Pairもメールアドレス+パスワードも同じ1つのAmazon Web Serviceアカウントを表すものですから、毎回生成するのはおかしな話なのです。
注意点としてはこの「4.生のままのKey Pair(Amazon EC2の一対の鍵)」を生成するのは、2011年7月時点ではメイン画面のアカウント→セキュリティ証明書画面ではなく、AWS Management Consoleで行うということです。混乱しやすいのですがこれも仕方ありませんね。
S3への接続認証キー
管理画面上ではS3への接続は証明書は使えません。Access Key+Secret Keyを使う必要があります。ここで使うのが「3.Access Key(アクセスキー)+Secret Key(シークレットキー)による認証(またはアクセスキーのみ)」です。 しかもS3の管理画面でその場で生成する画面は出てきません。アカウント画面のセキュリティ証明書画面の中で明示的に生成する必要があります。 この辺も統一されていないというわけです。 Access KeyとSecret Keyは人間が入力する事を考えておらずプログラムに設定してAmazonのAPIを呼び出す時にプログラムが使うユーザーID+パスワードのようなものです。なので文字数がとても多くて人間が覚えて入力できる文字数よりも長いためより安全であるということで採用されているようです。 この「Amazon EC2/S3の使い方」では、S3はシステムバックアップの為に使いますので、バックアップに使うツールが使用します。
ちなみに現在はS3の管理画面が存在しますが、これを書き始めた2010年の初め頃はS3に管理画面は無く、プログラムを組んで使う必要がありました。FireFoxのプラグインでS3の管理をおこなう事ができたのですが、API呼び出しを画面化してあるので、認証はAccess KeyとSecret Keyが必要でした。Amazonの管理画面にS3の管理画面がついて本当に便利になりました。
X.509証明書は?
認証といったら証明書というイメージがあると思うのですが、なんとここで説明している範囲ではX.509証明書は不要です。 アカウントメニューのセキュリティ証明書というところをこれから説明するのに、X.509証明書は必要ないって言うところが、また混乱してしまいますね。 先ほど公開鍵ペアを生成したじゃないか!と思うかもしれませんが、公開鍵ペアは生のままのKey PairでありX.509証明書ではありません。
セキュリティ証明書と呼ばれている各Keyの理解はできましたでしょうか? それぞれのKeyの生成は、必要なときに作業手順の中で説明します。