読者です 読者をやめる 読者になる 読者になる

Tomo's IT Blog

技術的な調査メモ

AWSのセキュリティの概要を学ぶ

AWSは非常に便利ですが、大規模な環境を容易に作成できてしまいます。第三者に不正利用されてしまうと、知らない間に大規模にEC2インスタンスが作成され、高額な請求がされてしまうという事になりかねません。現にアクセスキーをGitHubやブログなどにうっかり公開してしまい、それを第三者により使用され高額な請求が上がってしまったという事例もあるようです。CPUを大規模に利用してBit Coinの発掘をするのに利用したりされているようです。
AWS利用者としては、そのような不安を抱えながら利用したくはありません。そこでAWSのセキュリティはどのような仕組みで成り立っており、利用者はどのような考慮しなければならないのかを勉強していきたいと思います。

AWSセキュリティプロセスの概要

セキュリティの概要をまず理解するには、以下のドキュメントがちょうど良さそうです。

セキュリティプロセスの概要 | AWS

今回は、こちらを参照しながら勉強していこうと思います。

AWSのセキュリティモデル

f:id:tmnj:20170108175258p:plain

グローバルインフラストラクチャ

これは、AWS利用者ではなく、アマゾンウェブサービスが全面的に責任を負う部分になります。
AWS上で稼働するサービスのもととなる、ハードウェアやソフトウェア、ネットワーク・データセンターなどの施設で構成されます。この一番基盤となるインフラストラクチャを保護するのはAWSにとっては最優先事項となりますが、AWSの顧客は直接見ることは出来ません。その代わりに、サードパーティの監査会社からのレポートを受け取ることが出来るようになっています。

グローバルインフラストラクチャに加えて、マネージドサービスに該当するサービス(DynamoDB、RDSなど)の製品セキュリティもAWSの責任の範疇となります。以下のように記載されています。

これらのサービスについては、ゲストオペレー ティングシステム(OS)やデータベースのパッチ適用、ファイアウォールの設定、災害対策などのセキュリティタスクを AWS が行います。

AWS顧客が実施するのは、アカウントの認証情報を保護するのみとなります。
逆にマネージドサービスかどうかにかかわらず、アカウントの認証情報は顧客の責任でしっかりと管理する必要があります。これが漏洩して、不正利用されてしまっても、顧客の責任とみなされると思いますので、注意しましょう。よくあるのが、アクセスキーをうっかりコードの一部としてGitHubなどに公開してしまって、不正利用されてしまうことです。こういったことのないように自分が責任を持って保護しなければならない認証情報が何なのかを把握しておきましょう。そうすれば何も心配はありません!

マネージドサービス以外のIaaSに該当するサービス(EC2、VPC、S3)などの場合は、インスタンス含めて顧客がセキュリティタスクや、管理タスクなど完全に管理する必要があります。

逆にマネージドサービスは、そういった作業は不要です。
以下引用です。

マネージドサービスでは、インスタンスの起動や管理、ゲ スト OS やデータベースのパッチ適用、データベースのレプリケートなどに頭を悩ませる必要はありません。

ただし、先程も記述しましたが、認証情報の保護は顧客の責任となりますので、きちんと管理しましょう。

ただし、ユーザーに個々の認証情報を付与して役割分担を行えるように、Amazon Identity and Access Management(IAM)による AWS アカウント認証情報の保護と個々のユーザーアカウントの設定は、 他のサービス同様お客様自身で行う必要があります。また、AWS では各アカウントに多要素認証(MFA)を使用し、 AWS リソースへのアクセスに SSL/TLS の使用を義務付け、AWS CloudTrail で API/ユーザーアクティビティのログを記録 するように設定することを推奨しています。

AWSデータセンターのセキュリティ

Amazonはもともと、本業のリテールの方で大規模なデータセンター運用実績があり、ノウハウを持っていて、それをAWSの運用に活用しているようです。実際の運用経験をもとにしているので、普段からヘビーなAmazonユーザとしては、机上の空論ではなくこれほど説得力のあるデータセンター運用もないかと思います。
Amazonという最大の事例があるので、事例大好き日本人にはすごく安心できますよね!

データセンターも含めて、あらゆるサービスがすべてアクティブでN+1構成の考え方を原則にして構成されているようです。顧客がCloud上でシステムを構築する際は、従来のActive/Stanby型ではなく、あらゆるものをN+1アクティブ構成を基本に設計するのが今後のクラウド時代の鉄則となるのではないでしょうか。

ネットワークのセキュリティ

自分は、ネットワーク周りに苦手意識が強いので、今後は集中的に勉強していきたいと思っています。
AWSでは、ファイアウォールなどの境界ネットワークデバイスで、アクセス・コントロール・リスト(ACL)により設定ベースで制御できます。

また、セキュリテイグループなどにより、アクセスポイントに対してInbound/Outboudの通信許可を設定することが可能です。
ネットワークの監視機能もあります。

このあたりの詳細は、後日じっくりと勉強していきたいと思います。

AWSアカウントのセキュリティ機能

AWSにかぎらずに多くのクラウド利用ユーザの心配事は、自分のアカウントがちゃんと保護されていて、不正利用されないかどうかだと思います。
そのために自分のアカウントが不正利用されないようにしっかりと自身の認証情報を管理、保護しておく必要があります。
ただAWSでは不正利用から保護するための様々な機能を提供しているので、必要以上に恐れる必要はありません。ただし、自身が保護して置かなければならない情報が何なのかは、きちんと把握しておきましょう。当然パスワードなどのわかりやすいものは誰にもバレないようにするというのは、ITリテラシーの一般教養だと思いますが、万が一漏洩してしまったらとか、一見パスワードじゃないもの(アクセスキーなど)をうっかりコードに書いてGitHubにあげてしまった場合など、何が起きるかきちんと理解して適切な情報保護をしましょう!

AWSの認証情報の種類

AWSは複数の認証情報を利用して、AWSアカウント及びリソースへのアクセスを制御します。
アカウントに対して、他要素認証(MFA)を利用することも可能です。
以下、ASW認証情報の種類一覧になります。

認証情報の種類 使用アイテム 説明
パスワード AWS マネジメントコンソールへの AWS ルートアカウントまたは IAM ユーザーア カウントのログイン AWS アカウントまたは IAM アカウントへのログインに 使用する文字列です。AWS パスワードの最小文字数 は 6 文字、最大文字数は 128 文字です。
Multi-Factor Authentication(MFA) AWS マネジメントコンソールへの AWS ルートアカウントまたは IAM ユーザーア カウントのログイン AWS アカウントまたは IAM ユーザーアカウントにログ インする際に、パスワードに加えて要求される 6 桁の ワンタイムコードです。
アクセスキー AWS API へのデジタル署名付きリクエス ト(AWS SDKCLI、または REST/クエリ API を使用) アクセスキー ID とシークレットアクセスキーが含まれ ます。アクセスキーを使用して、AWS へのプログラム によるリクエストにデジタル署名します。
キーペア -EC2 インスタンスへの SSH ログイン
-CloudFront の署名付き URL
キーペアは、パブリック AMI から起動された EC2 イン スタンスに接続するときに必要になります。Amazon EC2 が使用するキーは、1024-bit SSH-2 RSA キーで す。キーペアは、インスタンスの起動時に自動的に生 成することも、手動でアップロードすることもできます。
X.509 証明書 - AWS API へのデジタル署名付き SOAP リクエスト
- HTTPS 用の SSL サーバー証明書
X.509 証明書は、SOAP ベースのリクエストに署名する ときにのみ使用されます(現在は Amazon S3 でのみ 使用されています)。AWS ではダウンロード可能な X.509 証明書とプライベートキーを作成できます。ま た、[Security Credentials] ページを使用して、独自の 証明書をアップロードすることもできます。


上記で特に注意しなければならないのは、アクセスキーです。アクセスキーはプログラムからAWSのリソースをコントロールする際に利用されますが、うっかりスクリプト内にアクセスキーを入れてたまま、GitHubやブログなど外部に公開された場所に情報を置いてしまい、それを元に不正利用されるということが実際に起こっているようです。ただ、アクセスキーは保護すべき対象ときちんと認識した上で、絶対に公開しない、不要なアクセスキーは作らないなどの対応を徹底しておけば問題ありません。なお、下記ブログの方は不正利用分は免除されたようです。良かったですね!AWSサポートは素晴らしいですね。

d.hatena.ne.jp

海外の方の事例もあります。こちらはうっかりGitHubに公開してしまったようです。

xingwu.me


念のため、不正利用が発覚した場合の対処方法は以下に載っていますので、いざという時には参照してみて下さい。

Resolve Issues with Potentially-Compromised AWS Accounts

なお、現在は、GitHubにアクセスキーをアップしてしまっていると、AWS側からアカウントがロックされてしまうこともあるようですので、お気をつけ下さい。

cohakim.com

何度も言いますが、アクセスキーは保護すべき重要な認証情報です。うっかり公開して後悔しないようにしましょう!

アカウント保護のポイント

アカウント保護のポイントとしては、

  • 認証情報は絶対に漏らさない。アクセスキーも含まれます。そもそもコード中に埋め込むという習慣はなくしましょう!IAMロールを活用することも検討すべきだと思います。
  • 多要素認証(MFA)をきちんと設定しておきましょう。(ただし、デバイスの機種変更などする際は、きちんと引き継げるように準備してから行いましょう!)
  • 適切な権限を絞るためにIAMユーザを作成しておきましょう。
  • 不要なアクセスキーは作らない。特にルートのアクセスキーを作成するのはなるべくやめておきましょう!


次回以降は、AWS個々のサービス毎のセキュリティを興味が出た順番で勉強していきたいと思います!