Developers.IO 2017セッション「ここからはじめるAWSセキュリティ」で話しました #cmdevio2017

クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「ここからはじめるAWSセキュリティ」を発表しました。そのレポートです。

発表スライド

はじめに

本セッションのゴール

セッションのゴールを2つ設定します。1つ目にセキュリティ対策が大切な理由を理解する事です。セキュリティは利益に直接結びつきにくいものですから、大切な理由を整理しておきたいと思います。2つ目にAWSのセキュリティに関するアクションがわかることです。この2つが達成できたら、このセッションは合格とさせて下さい。

アジェンダ

• 情報セキュリティとは
• IAMの重要性とベストプラクティス
• 証跡の取得
• 責任共有モデルで考える役割分担
• EC2の基本的なセキュリティ対策
• マネージドサービスの検討
• サーバーレスアーキテクチャの検討
• 補足

情報セキュリティとは

情報セキュリティの定義は色々ありますが、今回は"様々な脅威から、情報資産を機密性、完全性、可溶性の確保を行いつつ、 正常に維持する事"とします。セキュリティの話でよく出てくるワードとして、機密性、完全性、可用性があります。３大要件とか３要素とも呼ばれる言葉です。

機密性

セキュリティというと、機密性をイメージされる方が多いと思います。情報資産を正当な権利を持った人だけが、使用できる状態にしておくことです。

機密性が損なわれた状態を見て見ましょう。ファイルサーバーとその利用者を図にしました。
給与情報というフォルダと、営業データというフォルダがあります。人事部は給与情報のフォルダにアクセスできて、営業部は営業データにアクセスできるものとします。ファイルサーバーの設定に誤りがあると、営業部でも給与情報が見られるといった事態が発生します。機密性が損なわれていると言えます。

機密性が損なわれるパターン2つ目を紹介します。ある人がハードディスクの廃棄を業者に依頼したとします。業者は、ハードディスクを安全に廃棄してくれるはずのところを転売や譲渡してしまうと、機密性が損なわれてしまいます。

完全性

情報資産が正当な権利を持たない人により変更されていないことを確実にしておくことを指します。例としては、Web改ざんが挙げられます。ホームページのコンテンツを改ざんして、政治的なメッセージを載せられたり、マルウェアを配布するサイトに変えてしまうといった攻撃です。

可用性

情報資産を必要なときに使用できることをいいます。可溶性が損なわれた状態として、DDoS攻撃をあげます。攻撃者に乗っ取られたボットネットと呼ばれるパソコンやサーバから、不正な通信を送信したり、大量のアクセスを行う攻撃です。攻撃を受けたWebサイトは、正当なユーザーが繋げなかったり、繋げにくい状況になります。

IAMの重要性とベストプラクティス

AWSをセキュアに使うにあたり、IAMは重要です。IAM情報の流出や悪用は３大要件（機密性、完全性、可用性）が損なわれる可能性があるからです。

IAMを悪用された例

悪用される権限によりますが、ファイルストレージであるS3バケット内のファイルを不正にダウンロードされるといった事態が発生します。機密性が損なわれてしまうことを意味します。AWSの設定変更を行われてしまう恐れもあります。つまり、完全性が損なわれてしまいます。

IAMベストプラクティス

IAMを悪用されないために、IAMのベストプラクティスを実践する必要があります。ベストプラクティスはIAMのユーザーガイドに記載されていますが、特に重要なものをご紹介します。

IAMのアンチパターンをご紹介します。
1つ目に日常的なルートアカウントの利用です。初期アカウントであるルートアカウントは権限が非常に強いので、普段から使う事は辞めましょう。2つ目にIAMユーザーの共有です。複数人で1つのユーザーを使うことは辞めましょう。
ベストプラクティスとしては、1人につき、1つ以上のIAMユーザーを利用します。認証情報の共有はしません。

権限の付与は、IAMグループを通して行います。管理者権限を持つAdministratorsグループ、EC2に関しては、停止、削除、作成などなんでも出来るEC2Admin、閲覧権限のみ持つViewerなど役割に応じたグループを作成しましょう。

MFA設定

AWSコンソールにログインするユーザーでは、MFAを設定してください。ログイン時に入力するユーザー名、パスワードに加えてMFAデバイスが表示する６桁の数字を追加できます。数字は30秒ごとに変化するので、コンソールログインに関するリスクを低減できます。

MFAデバイスは、物理デイバスト仮想デバイスに分けられます。
物理デバイスのイメージとしては、スライドにあるようなキーホルダー型のものやカード型のものがあります。物理的なモノですので、鍵付きのロッカーに保存するなど、統制が取りやすいメリットがあります。反面、電池切れがあったりかさばりやすいといったデメリットがあります。仮想MFAデバイスは、スマートフォンなどにインストールするタイプです。スマートフォンはほとんどの方が持っていますから、導入は簡単です。 物理MFAデバイスと比べると、統制が取りづらいデメリットがあります。

IAMキーの登録とIAMロール

アンチパターンとして、EC2へのIAMキーの登録をあげます。ファイルバックアップなどの用途で、AWS CLIやSDKを実行することがあります。CLIやSDKは、登録したキーの権限で実行されます。キーの登録自体に直ちに問題があるわけではありませんが、キー情報が服回れたプログラムや設定ファイルをブログやリポジトリにあげてしまう事故が多発しています。

キーの代わりに、IAMロールをお勧めします。IAMロールをEC2に割り当てると、キーの登録がいらなくなります。以前は起動中のEC2へのロールの割り当て、割り当て解除が出来ませんでしたが、出来るようになりました。キーの漏洩を防ぐために、ロールを使いましょう。

IAMの定期的な見直し

ベストプラクティスとして、IAMの定期的な見直しをお勧めします。 異動や退職に伴うIAMユーザーの追加、削除が必要です。チームから外れた人がいれば、IAMユーザーを削除しましょう。検証でキーを一時的に作成するといったことがあります。検証が終わったら、キーを削除しましょう。不要なIAMユーザーやキーがないか定期的に見直します。

IAMの見直しについて、IAM認証情報レポートを使うと便利です。CSVでダウンロードできるファイルです。レポートの確認方法を紹介します。 MFAが有効でないアカウントの特定は、password enabledと、mfa_activeに注目します。password enabledがtrueだと、AWSコンソールへのログインが可能です。ログイン可能かつMFA無効のアカウントが、MFAを有効にすべきアカウントです。

利用されていないアカウントは、password_last_used、access_key_1_last_used_dateに注目します。一定期間ログインしていない、アクセスキーを使っていない場合、利用されていないアカウントの可能性が高いです。ユーザーを削除するか検討します。

証跡の取得

AWS CloudTrail

抑えておきたいのが、AWS CloudTrailというサービスです。
AWSコンソールでEC2を起動したり、停止すると裏ではAWSのAPIが実行されます。CloudTrailはAPIのログを記録し、S3にアップロードします。ログの内容としては、時間、ユーザー、アクション、送信元IPなどです。IAMの悪用が疑われるケースで、何があったのかなかったのか確認できるので、CloudTrailは有効化を強くお勧めします。

AWS Config

CloudTrailと合わせて有効化したいのが、AWS Configです。
AWSの構成記録をとるサービスで、AWSリソースの作成や変更を記録できます。タイムラインで確認できるため、人が見てわかりやすいサービスです。

セキュリティグループのタイムラインを紹介します。四角のボックスであるタイムラインに日付と時間が表示されています。何かしらの変更が行われると、タイムラインが追加されます。セキュリティグループの場合、EC2に割り当てたり、ルールを変更した場合に追加されます。タイムラインを選択すると、FromとToという形で変更前後の設定内容を確認できます。

AWS ConfigとEC2 System Managerを連携させる事で、OSのアップデート状況についても追跡できます。EC2にSSMエージェントをインストールすると、EC2 System Managerにソフトウェアのバージョン情報が送信されます。バージョンに変更があると、AWS Configのタイムラインに記録されます。
カーネルアップデート前後のFromとToを紹介します。Fromつまり変更前は、バージョン4.4.41である事がわかります。変更後のToを見ると、4.4.44になった事がわかります。インストール日時についても確認できます。こういった形でOSアップデートについても追跡できます。

各サービスのログ有効化

本番環境でELBやCloudFrontを使う場合は、ログ配信を有効化しましょう。ELB、CloudFrontは、S3にアクセスログを出せます。トラブルシューティングや、サポート問い合わせに必要になります。

責任共有モデルで考える役割分担

AWSのセキュリティは、AWSとユーザーが連携して達成します。それぞれの担当範囲を定めたものが責任共有モデルです。AWSはクラウドのセキュリティを担当し、ユーザーはクラウド内のセキュリティを担当します。責任共有モデルでは、サービスによって、担当範囲が異なります。

インフラストラクチャサービスの責任共有モデル

インフラストラクチャサービスの、責任共有モデルの概要です。EC2などが該当します。左側がユーザーの担当、右側がAWSの担当です。
AWSは基盤サービスやAWSグローバルインフラストラクチャと呼ばれる、インフラ周りを担当します。ユーザーは、基本的にOS以上のレイヤを担当します。

EC2における担当の例

担当の例を2つ紹介します。1つ目ディスクの廃棄はAWSが担当します。ディスクの廃棄以外にも、データセンターの管理などはAWSの担当です。
2つ目にEC2のOS、ミドルウェアのバージョンアップをあげますが、こちらはユーザーの担当です。Apache Struts2の脆弱性が話題になりましたが、そういった脆弱性対応はユーザーの対応範囲です。

EC2の基本的なセキュリティ対策

AWSで最もポピュラーなサービスでさるEC2のセキュリティ対策をご紹介します。

信頼できるAMIを使う

EC2は基本的にAMIから作成します。AMIは誰でも公開できるため、中には悪意のあるものが含まれる可能性があります。AWSや信頼できるベンダーが提供するAMIを利用しましょう。ネット検索で出てきたAMI IDをよく確認せずに利用することは、辞めましょう。

Windowsの日本語AMIを使いたい場合は、プラットフォームWindows、AMI名にWindows Server 2012 R2 Japaneseといった形で指定します。これだけだと、どこかの誰かが公開したAMIの可能性があるので、所有者にAmazon イメージを選択しておくと安心です。
AWS以外がベンダーが提供するAMIを利用する場合は、AWS Marketplaceで提供元を確認しておくと良いと思います。

セキュリティグループでは、必要な通信のみ許可

EC2のセキュリティグループでは、必要な通信のみ許可するようにします。
送信ルールについては、全て許可とすることが多いです。要件に応じて制限を追加してください。NTPの同期、AWS API、パッチ適用、アプリケーションに必要な通信をブロックしないようにしてください。

最新のOS、ミドルウェアを使う

EC2では、最新のOS、ミドルウェアを使いましょう。サポート期限が切れたOSでは、基本的にセキュリティパッチが提供されません。また、古いOSやミドルウェアには、脆弱性がある可能性があります。
最新のOS、ミドルウェアを使い、定期的にアップデートしましょう。 プラットフォーム診断をして、脆弱性のあるOSやミドルウェアを使っていないか確認します。プラットフォーム診断は、AWSのサービスであるInspectorを使ったり、専門のベンダーに依頼します。

最新のアプリケーションを使う

アプリケーションについても、最新のものを使います。古いアプリケーションには、脆弱性があることが多いです。OS、ミドルウェアと合わせて最新のバージョンを使いましょう。
一般公開するWebアプリケーションの場合は、専門のベンダーに依頼しアプリケーション診断する事をお勧めします。診断を行う場合、事前の申請が必要なので注意してください。

マルウェア対策

マルウェア対策のために、ウイルス対策ソフトとホスト方式のIDSソフトウェアを導入しましょう。IDSでは、重要なシステムファイルなどを変更されていないかチェックし、変更された場合は通知できます。
IDSですが、AWSのセキュリティベストプラクティスではOSSECが紹介されています。商用製品がいい場合は、Deep Securityなどがあります。

ブラックリスト登録

特定IPからの攻撃が認められた場合、そのIPアドレスからの接続をブロックできます。
Network ACLを使った方法が一番、手軽です。Netwrok ACLはVPCのサブネット単位で設定できます。デメリットとしては、ルール上限数が少ないです。
AWS WAFを使う方法もあります。AWS WAFはCloudFrontまたは、ALBに設定します。ルール上限数が多いため、大量のブラックリスト登録に適しています。

特定の国からの接続のブロック

Amazon CloudFrontでは、GeoIPを使った国ごとの許可、拒否を設定できます。特定の国からの攻撃が認められるケースでは、有効です。 ただし、GeoIPは必ずしも正確ではない点に注意が必要です。

マネージドサービスの検討

AWSを使い始めたばかりの方は、主にEC2を使われると思います。EC2を別のサービスと組み合わせたり、別のサービスに置き換えることで、クラウドのメリットを受けられます。

WEBサーバでは ELBを検討

WEBサーバを使っている場合は、ELBを検討します。ELBはロードバランサーのサービスです。負荷分散するだけでなく、セキュリティや運用上のメリットがあります。3つあげます。
1つ目に、有効なTCPリクエストのみサポートされます。SYNフラッドのような攻撃に使われる通信はELBでブロックし、EC2に到達しません。
2つ目にSSLターミネートをあげます。ターミネートをELBで行うことで、EC2のCPU負荷を減らせます。また、EC2にターミネートに必要なミドルウェアを入れる必要がなくなります。インストールやアップデートを行う手間を減らせるという事です。
最後に、EC2のローリングアップデートです。OSやミドルウェアのパッチ適用は再起動が必要なことが多いので、ELBによる冗長化にメリットがあります。

DBサーバでは RDSを検討

DBサーバについては、RDSを検討します。RDSはAWSのマネージドなリレーショナルデータベースサービスです。

RDSはコンテナサービスに該当します。責任共有モデルをEC2と比較するとAWSの担当が増え、ユーザーの担当が減っています。ユーザーの担当範囲が減ることで、構築や運用の手間を減らせます。

RDSはメンテナンスが全く不要なサービスではありません。ユーザーの担当範囲の代表的なものをあげます。
週時のメンテナンス時間であるメンテナンスウィンドウや、メンテナンス実施タイミングの指定が必要です。メンテナンスが計画された時に、すぐに実行するのか、次回のメンテナンスウィンドウまで待つのか選択します。
冗長化するのか、シングル構成にするのかについても、選択が必要です。冗長化することで、メンテナンス影響を最小限にできます。本番環境では冗長化が推奨されますが、コストと相談しつつ選択します。メンテナンスの通知などがあるので、AWSからのメールを確認しましょう

RDSのメリットを3つ紹介します。
1つ目に冗長化が簡単です。
2つ目にDBエンジン、OSの更新が簡単です。DBサーバへのパッチ適用は、DBに詳しいエンジニアがいないと中々怖くてできないと思います。 RDSの場合はDBエンジニアでなくても更新できるため、セキュアな状態を保ちやすいです。
最後にバックアップ、リストアについても、簡単です。正常なバックアップを取って、現実的な時間でリストアするには高いスキルが必要です。RDSであれば、簡単にバックアップリストア出来ます。
RDSは、DBに関する全てをいい感じにやってくれるわけではありません。簡単な設定をしておけば、専門知識が必要な作業を簡単に実施でき、 結果的にセキュリティを保ちやすいメリットがあります。

サーバーレスアーキテクチャの検討

セキュリティの観点から、サーバーレスアーキテクチャを検討します。AWSのマネージドサービスを組み合わせることで、サーバの管理が不要になります。
例として静的なWebサイトの場合は、S3とCloudFrontを使う形が一般的です。S3に静的コンテンツを配置し、CloudFrontでキャッシュします。ユーザーがサイトにアクセスすると、地理的に近いキャッシュサーバーにアクセスされるので最短距離でコンテンツを配信できます。また、S3はEC2と比べて低コストです。セキュリティ面のメリットですが、ユーザー側でOSやアプリケーションのパッチ適用を意識する必要はありません。

抽象化サービスの責任共有モデルの概要

ユーザーの担当が少ないです。パッチ適用などのセキュリティ対策は、事前の検証など大変だと思います。ユーザの担当範囲が少ないサービスを使うことで、セキュアな状態を保ちやすくなります。
S3の設定は、ユーザーの担当である点に注意してください。設定次第では、誰でも読み書きできる状態になります。

補足

AWS Trusted Advisorを使ったレビュー

AWS環境の見直しに、Trusted Advisorをぜひ使っていただければと思います。Trusted Advisorはコスト、パフォーマンス、セキュリティ、耐障害性の観点で環境の評価をするサービスです。
セキュリティに関しては、セキュリティグループが無制限に許可されていないか、CloudTrailが有効になっているか、S3のアクセス許可がオープンになっていないかなど確認できます。

AWSからの連絡を無視しない

AWSからの連絡を無視しないようにしてください。
メンテナンス情報、セキュリティインシデント、違法行為の通知など重要な連絡があります。セキュリティインシデントで例を挙げますと、IAM情報の漏洩が疑われる時に教えてくれることがあります。また、意図せずスパムメールを送ってしまったり、ウイルスに感染してDDoS攻撃に加担してしまっている時も通知してくれます。

違法行為の通知を受け取ったら

違法行為の通知を受け取ったら、AWSからの要請に対応する必要があります。放置した場合、最悪の場合AWSアカウントやインスタンスを停止される可能性があります。また、社内的な信用に影響が出たり、被害者から訴訟を受けるリスクがあります。

スパムメールを送信しまうケースでは、オープンリレーになっていないかなど確認します。
DDoS攻撃への加担では、EC2の送信ルールを最小限に絞る形で隔離し、必要なデータを抜き出します。 EC2はマルウェアに感染している可能性があるので、インスタンスは破棄しましょう。クリーンなEC2を使って、デプロイし直すといった対応が必要になります。

脅威分析

セキュリティ対策をご紹介しましたが、完璧なセキュリティ対策は存在しません。個々のシステムが抱えるリスクを洗い出して、コストと相談しつつ優先度から高いものから対応して頂くと思います。

まとめ

セキュリティの３大要件を紹介しました。機密性、完全性、可用性です。
AWSのセキュリティにおいて、IAMは非常に重要です。IAMの漏洩や悪用は、３大要件が損なわれる可能性を意味します。IAMベストプラクティスに従い、定期的に見直しましょう。 AWS CloudTrail、AWS Configを使うと、証跡を取れます。何があったのかなかったのか追跡できるので、有効化をお勧めします。
AWSのセキュリティはユーザーとAWSが協力して対応する責任共有モデルを紹介しました。

EC2のセキュリティ対策ですが、信頼できるAMIを使うなどAWSならではの対策もありますが、パッチ適用など一般的なセキュリティ慣行も重要です。
EC2だけでなく、EC2以外のマネージドサービスについて、検討しましょう。責任共有モデルにおけるユーザーの担当範囲を小さくし、パッチ適用などで楽をしましょう。楽をすることで、結果的にセキュアな状態を保ちやすくなります。

完璧なセキュリティ対策は存在しません。ご紹介した内容と合わせて、ここのシステムに必要な対応を実施してください。