本記事は、セミナーで実施したデモの内容を記載しております。

セミナー参加後の振返りにご利用ください。

マネジメントコンソールにサインインして、S3のバケット名一覧を見る方法と、CLI(コマンドラインインターフェース)から同じようにS3バケット名一覧を見る方法を比較します。

認証方法がそれぞれ違うことをご確認ください。

マネジメントコンソールへの認証

マネジメントコンソールへのサインイン

Webページで公開されている誰でもアクセスできる、リンクやボタンからマネジメントコンソールのサインイン画面にアクセスします。

12桁のアカウントID、IAMユーザー名、パスワードを入力してサインインします。

この3つの情報が漏れてしまうと、不正アクセスされてしまう可能性があります。

オプションでサインインした後にさらにMFA(Multi-Factor Authentication)の設定が可能です。

私の場合はGoogle AuthenticatorというiPhoneアプリを使用しています。

30秒ごとに変わる6桁の数字を入力しないとサインインができません。

6桁の数字なのでアタックされればいつかはやぶられるかもしれませんが、3回失敗すると再同期が必要となります。

オプションなので設定するしないは、お客さまに選択が委ねられますが、必ず設定することを推奨します。

繰り返しになりますが設定していないと、12桁のアカウントID、IAMユーザー名、パスワードが漏れれば不正アクセスされてしまいます。

マネジメントコンソールにサインインが完了したのでS3バケットの一覧を見てみます。

バケット名が表示されました。

CLI(コマンドラインインターフェース)からの認証

これと同じことをCLI(コマンドラインインターフェースから実行してみます)

デモ用に起動したEC2インスタンスにターミナルからSSHログインして操作します。

$ aws s3 ls

Unable to locate credentials. You can configure credentials by running "aws configure".

バケットの一覧を表示するコマンド「aws s3 ls」を実行しましたが、"認証情報がない"というエラーになりました。

コマンドラインインターフェースから認証を行う場合は、IAMユーザー名とパスワードではなく、アクセスキーIDとシークレットアクセスキーを使用します。

権限を持っているIAMユーザーのアクセスキーを発行します。

「aws configure」コマンドから設定します。

$ aws configure
AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Default region name [None]: ap-northeast-1
Default output format [None]: json

もう一度「aws s3 ls」コマンドを実行します。

$ aws s3 ls
2018-08-23 07:14:03 takufile
2017-06-04 03:12:26 tunecore-8bangi
2017-07-08 01:14:44 uriwari-hey-mail
2019-04-13 16:15:20 yamamanx-cloudfront-log
2019-04-13 16:15:05 yamamanx-mail

マネジメントコンソールの画面に表示されたのと同じバケット名一覧が表示されました。

アクセスキーが漏れると

しかし、このIAMユーザーのアクセスキーを使用する方法は非推奨です。

なぜならアクセスキーIDとシークレットアクセスキーが漏れると不正アクセスされるためです。

実際にアクセスキーIDが漏れてしまって不正アクセスされた事件が発生しています。

アクセスキーが漏れたことによって、不正アクセスしたユーザーは仮想通貨のマイニングのために大きなサイズのEC2インスタンスをいくつも起動します。

それにより高額な請求が発生してしまう場合もあるかもしれません。

それだけならまだしも、そのアクセスキーのIAMユーザーに過剰な権限を設定してしまっていることにより、個人情報や機密情報を格納しているS3バケットにアクセスされてしまうかもしれません。

そうなると、警察や個人情報保護委員会などに報告をし、第三者機関に調査を依頼しなければなりません。

CloudTrailが有効な環境であれば、このアクセスされているかどうかの調査も行えますが、CloudTrailが無効な場合はもうお手上げです。

漏洩したかもしれません、という謝罪をしなければならなくなります。

もちろん、調査の結果、万が一漏洩しているときにも問題となります。

• アクセスキーはなるべく使わずにIAMロールを使う。
• IAMユーザーの権限ポリシーは最小権限で設定。
• CloudTrailは有効にする。

これらはセキュリティのベストプラクティスです。

アクセスキーを使わずに、同様にCLIやSDKで実行するプログラムに権限を付与できるのが、IAMロールです。

IAMロールを使ってEC2上で実行するCLIで認証する

先ほどのアクセスキーをIAMユーザーから削除して、もう一度「aws s3 ls」コマンドを実行します。

$ aws s3 ls

An error occurred (InvalidAccessKeyId) when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records.

アクセスキーを削除したのでエラーとなります。

(アクセスキーそのものが存在しないので、.aws/credentialsファイルも削除しておきます)

EC2向けのIAMロールを新規作成して、インラインポリシーで、S3のListAllMyBucketsのみを有効にします。

作成したIAMロールを稼働中のEC2に設定します。

コマンドを実行します。

$ aws s3 ls
2018-08-23 07:14:03 takufile
2017-06-04 03:12:26 tunecore-8bangi
2017-07-08 01:14:44 uriwari-hey-mail
2019-04-13 16:15:20 yamamanx-cloudfront-log
2019-04-13 16:15:05 yamamanx-mail

CLIから認証が行えてバケットの一覧が表示されました。

IAMロールを使用することで安全に認証情報を設定できました。