Amazon EC2のセキュリティレシピ
はじめに
セキュリティという言葉は様々なシーンで使われます。
マルウェア、暗号化、改ざん、スパム、ブルートフォースアタック、内部不正、ログ管理、ログ監視、DDoS対策など例をあげるときりがありません。
今回はAWSを利用する際にユーザーが最低限行うべき対応をご紹介します。
AWSには様々なサービスがありますが、以下のようなEC2 1台のWEBサーバを想定しそのセキュリティ対策を考えます。
ご紹介する項目は以下の通りです。
- 信頼できるAMIを使う
- 最新のOSを使う
- 必要なポート、必要な拠点のみ接続を許可する
- 最新のミドルウェアを使う
- マネージドサービスに任せる
- 最新のアプリケーションを使う
- IAMロールを使う
- 最低限のIAM Policyを設定する
- 日頃からAWSからのメールを確認する
信頼できるAMIを使う
EC2は基本的にAmazon マシンイメージ（AMI)から作成します。
AMIはAmazonやAWSパートナー以外の第三者も公開することが出来るため、悪意のあるAMIを利用しないように気をつけます。
例えば、掲示板やブログに記載されたAMI-IDを確認せずに利用する事はやめましょう。
EC2コンソールでは、所有者をAmazonに絞って表示することが出来ます。
WindowsServer 2012R2の日本語版を表示する例を示します。
AWS Marketplaceから信頼できるパートナーやコミュニティが提供するAMIを利用する手もあります。
CentOSの場合、CentOS.orgが提供するAMIを利用すると良いでしょう。
最新のOSを使う
OSは一般的にサポートを受けられる期限が決められています。
期限をすぎるとセキュリティパッチなどが提供されません。
重大な脆弱性が見つかってもセキュリティパッチを適用出来ないといった事は避けたいです。
アプリケーションの制限により古いOSを使うケースもありますが、最新OSの利用を基本とします。
必要なポート、必要な拠点のみ接続を許可する
EC2のアクセス制限は主にセキュリティグループで行います。
セキュリティグループはファイアウォールに相当する機能です。
接続を許可するプロトコル、ポート番号、送信元IPアドレスを記載します。
WEBサーバに適用するセキュリティグループの例をあげます。
サービス公開用のHTTPSは、送信元に「0.0.0.0/0」を指定します。
「0.0.0.0/0」とする事でインターネット全体からの接続を許可します。
開発中は開発拠点からだけ接続できるようにしても良いでしょう。
サービス利用者のIPが特定出来る場合は、利用者のIPを指定します。
管理用のSSHやリモートデスクトップは、最低限の許可を与えます。
具体的には開発会社やAWS管理者などメンテナンス拠点のIPアドレスを指定します。
| タイプ | プロトコル | ポート範囲 | 送信元 |
| HTTPS | TCP | 443 | 0.0.0.0/0 |
| SSH | TCP | 22 | メンテナンス拠点のIPアドレス/32 |
最新のミドルウェアを使う
古いミドルウェアには脆弱性が含まれることがあります。
脆弱性によってその影響は様々です。
外部から比較的容易にサービス断を行えるものや、不正なコマンドを実行され情報を抜き取られるなどよりクリティカルなものもあります。
最新のミドルウェアを利用し定期的にアップデートするようにします。
ミドルウェアの脆弱性が見つかると、脆弱性情報データベースや各ベンダで公開されます。
Common Vulnerabilities and ExposuresやJapan Vulnerability Notesが有名です。
Amazon Linuxの場合、Amazon Linux AMI Security Centerで公開されます。
各サイトを巡回するには骨が折れるため、RSSやtwitterで情報収集されるかたも多いかと思います。
影響が大きい脆弱性については、全社周知が行われる組織もあります。
AWSサービスを使って環境を評価する事も出来ます。
Amazon Inspectorでは、Common Vulnerabilities and Exposuresに基づいて、脆弱性を確認出来ます。
利用には専用のエージェントが必要です。
マネージドサービスに任せる
セキュリティの観点からマネージドサービスを検討しましょう。
マネージドサービスを利用する事で環境をセキュアにしつつ、TCOを下げる効果を期待出来ます。
スタンドアローンのEC2を例に考えます。
アプリケーションの要件としてApache/PHP/MySQLが必要とします。
ユーザーはWebサイトに"HTTPS"でアクセスします。
SSLを終端させるためにOpenSSLを利用し証明書をEC2上に配置します。
この場合、少なくともApache/PHP/MySQL/OpenSSLのアップデートが必要です。
また、アップデートにはOSの再起動が必要だったり推奨される事が多いため、EC2スタンドアローン構成ではアップデートによるサービス影響が大きくなります。
マネージドサービスを利用するケースを考えます。SSL終端をELB、MySQLにRDSを使う構成とします。
EC2上のOpenSSLとMySQLが不要になり管理するミドルウェアの数を減らす事が出来ます。
ELBを使うメリットはほかにもあります。3つ挙げてみます。
1つ目にSSL終端にはCPUパワーを使うため、EC2の負荷を下げる事が期待出来ます。EC2はhttpとしてアクセスを受け取ります。
2つ目にAWS Certificate Manager(ACM)の無償のSSL証明書の利用です。ACMでは更新不要な証明書を利用できますが、EC2上に配置する事は出来ません。認証局から証明書を購入する費用や更新の手間が不要になります。
3つ目にアップデートに伴うサービス影響の軽減です。EC2利用費用はかかりますが、EC2を複数配置し順番にアップデート（ローリングアップデート）する事でサービスを継続しながらアップデートを行えるようになります。
RDSでは自動的にパッチ適用やバックアップを行います。また、冗長構成（Multi-AZ）を簡単にとる事が出来ます。
Multi-AZ構成の場合、パッチ適用のサービス影響は非常に小さくなります。
EC2で頑張らずにマネージドサービスに任せましょう。
最新のアプリケーションを使う
ミドルウェアと同様にアプリケーションについても、最新のアプリケーションを利用します。
古いアプリケーションは脆弱性を持っていたり、古いライブラリを利用する場合があるためです。
アプリケーション構築がひと段落したら、アプリケーション診断を行っても良いでしょう。
運用後も半年や1年など定期的に診断し、適宜対応を行います。
IAMロールを使う
EC2からAWS CLIなどを実行する事があります。
例えば、OS上のファイルをs3バケットにアップロードするようなケースです。
AWS CLIを実行するにはs3の利用権限が必要です。
以前はIAMユーザのAccess Key、Secret Keyを使う方法が一般的でしたが、現在は推奨されていません。
Keyが流出し第三者に悪用されるケースがあるためです。
具体的にはプログラムや設定ファイル中にKeyを記載し、意図せずKeyを公開してしまうといったケースです。
現在はIAMロールの利用が推奨されています。
IAMロールを利用する事で、EC2上にKeyを配置する必要がなくなります。
最低限のIAM Policyを設定する
前述のIAMロールには、IAM Policyを割り当てます。
IAM PolicyはJSON形式のアクセス許可を記述したドキュメントです。
IAM PolicyにはAWSが作成/管理するAWS 管理ポリシーとユーザーが作成/管理するカスタマー管理ポリシーがあります。
カスタマー管理ポリシーではより正確なアクセス許可を記述出来ますが、管理が複雑になりやすいです。
セキュリティ要求が厳密に求められる場合に検討します。
AWS 管理ポリシーは、サービス毎に数パターン用意されています。
s3では「AmazonS3ReadOnlyAccess」「AmazonS3FullAccess」「AmazonDMSRedshiftS3Role」があります。（2016/11/6時点）
基本的にはAWS管理ポリシーの範囲で最低限のIAM Policyを利用すると良いでしょう。
s3にファイルバックアップを行う場合には「AmazonS3FullAccess」です。
むやみに「AdministratorAccess」など大きい権限を与えないようにします。
日頃からAWSからのメールを確認する
AWSからメールの中には重要なものが含まれる事があります。
特にEC2のリタイアメントを受け取る機会が多いでしょう。
インスタンスをホストしている基盤のハードウェアで回復不可能な障害が検出されると、AWSによってインスタンスのリタイヤが予定されます。
インスタンスのStop及びStartの操作を行うことにより、EC2インスタンスをホストする物理マシンを変更し、AWSによるインスタンス停止を回避することが出来ます。
期日までに回避操作を行わないと、EC2はStopされます。
不正利用を通知するAbuse reportについても留意が必要です。
例えばインスタンスが第三者にのっとられた場合、DDoS攻撃に利用されるなど不正利用される場合があります。
AWSから不正利用が疑われる旨のAbuse reportが通知された場合、ユーザーは適切な対応を行いその旨をAWSに報告する必要があります。
Abuse reportはAccess Key、Secret Keyの流出が疑われる場合も通知されます。
AWSからのメールを確認し、重要な通知を見逃さないようにしましょう。
終わりに
Amazon EC2の基本的なセキュリティ対策について、整理しました。
基本的な対策を実施しつつ、不足する内容をフォローするとしっかりとしたセキュリティ対策が出来ると思います。