「【エンジニア編】AWS活用を考えているなら”必ず！”知っておくべきセキュリティの話」参加レポート

大阪出張中の丹内です。 アマゾン大阪オフィスで開催された、【エンジニア編】AWS活用を考えているなら”必ず！"知っておくべきセキュリティの話に参加したのでレポートします。
なお、ビジネス編のレポートはこちらになります。

発表

AWSを利用する上で知っておくべきセキュリティ事項とセキュリティ関連サービスの紹介

登壇者はアマゾンウェブサービスジャパン株式会社 パートナーソリューションアーキテクトの小梁川 貴史氏です。

お馴染みの責任共有モデルから始まりました。会場でも半数の方が聞いたことがあるようでした。これは、総合的なセキュリティを保つため、AWSはクラウドのセキュリティに、ユーザはクラウド内のセキュリティに責任を分担して持つという考え方です。「セキュリティをAWSにオフロードする」という表現をされていて、しっくりきました。
RDSなどマネージドサービスを使う場合は、AWSがミドルウェアまで責任を持つので、メンテナンスウィンドウを設けてパッチを適用するなどの操作を行います。
セキュリティに関する具体的なアクションを起こす前に、守るべき資産を特定することが第一歩です。敵は外部だけではなく、内部ということもありえます。例えば、情報漏えいは内部犯行が80%と言われているそうです。何を、誰から守るのかを定義してから、ログや監査など適切な対策を行います。
開発者視点だと、非機能要件で抜けがちなので、可能な限り自動化することが望ましいです。

• 開発時は暗号化を選択したりサービスを利用したり、鍵/パスワードの管理を徹底したり、監査自動化
• 運用時はパッチ対応、バージョンアップ、パスワードの定期更新
• 全期間と押して、社内ルールを確認したり、運用ルールを作成

鍵になるのは自動化と言えます。セキュリティ起因での対応が発生することを考えると、テンプレートやIAMデプロイの仕組みなど、徹底的なデプロイ対策を行ったほうが良いです。
また、開発者が特に気をつけることとして、AWS ACCESS KEYの公開(gitに含めてしまう)、意図のないポート全開放、分かりやすいユーザ名/パスワードなどがあります。
それに加えて、AWSが送ってくるAbuse Reportというものがあるらしく、上記のようなセキュリティ上好ましくない使い方をしているユーザに送られてくるメールを無視し続けると、機能停止やアカウント停止などが行われることもあるらしいので、気を配る必要があります。
開発時に開発すべき非機能要件として扱い、いかに開発・運用工数を少なくするかを考えると実務でも進めやすいです。

AWSのサービス群の１つであるTrusted Advisorを使って、指摘されているセキュリティ要件があるかを確認することから始めるのがオススメとのことです。

Trusted Advisor以外にもセキュリティに関わるサービスはいくつかあります。
IAMはもちろん、KMSも該当します。KMSは鍵の管理を一元化できます。最近、ユーザ側からの鍵の持ち込みにも対応しました。
CloudWatch(Logs)もセキュリティ上重要です。
知名度がイマイチなようなAWS Configは、AWSリソースの設定変更を履歴として残し、管理してくれるサービスです。
CloudTrailは非常に重要です。私もAWSをアカウントを作ったら最初に全リージョンで有効化します。監査ログはJSONで生成されるので、DatadogやElasticsearchで可視化することもできます。発表では、CloudTrailの監査ログを監査用の別AWSアカウントのS3に集約し、監査用アカウントのLambdaで解析してSNSによるアラートを設定するという、社内統制・管理の一元化・監査定義の変化への対応を成立させるパターンが紹介されていました。

セキュリティもクラウドを使って上手に自動化！DevSecOpsを考えてみる。

登壇者はトレンドマイクロ株式会社 パートナービジネス推進部 アライアンスパートナーグループ シニアスペシャリストの南原　正樹氏です。

セキュリティ業界は日々成長していますが、その背景として以下のものがあります。

• 標的型攻撃やマルウェア、攻撃手法が常に変化していること
• 日々発見される脆弱性。技術的なことだけではなく、心理的要素や人為的ミス
• 情報資産の発展。受け入れるマーケットがあり、価値が上がる

そしてこれらは日々変わるため、特定の基準でのアセスメントは困難と言えます。今までターゲットではなかった企業がターゲットになり得ます。
その対抗となるセキュリティ人材も不足しており、高まるニーズと合わせて、どのようにデータを守るかというのが課題になっています。

AWSの責任モデルのうちユーザの責任を、コードでシンプルに管理することをSecurity as a Codeと呼び、DevOpsに加えてSecurityも開発者と行っていくという考え方がDevSecOpsです。

DeepSecurityとは、EC2にエージェントをインストールして使うセキュリティ製品です。
導入はシンプルですが、多層防御(様々なレイヤ・要素での防御)に対応した製品で、制御UIもある管理しやすいソリューションです。
AWSの機能を活用しており、特定のEC2タグが付いているものに適用するポリシー、特定のSecurity Groupsに適用するポリシーも設定できます。
REST APIもあるため、Lambdaとの連係もできます。その連係ツールはgithubで公開されており、必要ならトレンドマイクロ社の支援を受けられます。

Deep Securityを使ったDevSecOpsの実例は以下のとおりです。

• 予測・評価：Amazon InspectorでEC2の監査を行い、Deep Securityがアセスメント結果を受け取り脆弱性診断を行なう
  • 診断後はDeep Securityで守る
• 検知・防御：Deep Securityがインスタンス情報をもとにAWS WAFを制御する
• 監視・対処：SNSからイベントを起こし、自動で対処する
• 監査：AWS Configと連携し、準拠すべきルールに基づいた構成変更が行われているかを評価する
  • AWS Configが使うカスタムルールはGitHubで提供されている

Deep Securityを使うことでセキュリティを自動化し、変化する攻撃に対応することができます。

AWS WAFとDeep Securityを連携させてみた

登壇者は弊社AWSコンサルティング部 ソリューションアーキテクトの森永 大志です。

AWS WAFについてのセッションです。WAF(Web Application Firewall)とは、Webアプリケーションへの攻撃を防ぐミドルウェアで、AWS WAFはその名の通りAWSが提供するWAFとなります。

AWS WAFは以下の要素で構成されます。

• Web ACL
• Rule
• Condition

Conditionとは、攻撃を判定するための要素を定義するものです。攻撃元IPアドレスや対象とするSQLインジェクション、それ以上は攻撃とみなす文字列長やサイズなどがあります。検知するフィルター部分のみで、実際の防御は別のレイヤです。
Ruleは、AND条件でConditionをまとめます。ANDなので両方のConditionが該当しないと防御が行われないので注意が必要です。
Web ACLは、RuleやConditionで検知したリクエストにどのように対処するかを定義するものです。ルールに該当する/しないリクエストを許可/拒否/カウントすることができます。
AWS WAFはCloudFrontに紐付けるサービスです。CloudFrontにIP制限がかけられるので、リリース前のコンテンツ秘匿などに応用することができます。

Deep Securityと組み合わせることで、以下の機能が実現できます。

• Conditionの作成
• WAFの制御

デモでは、まずDeep Security ManagerというWebブラウザで使うコンソールからユーザを作成します。
次にdeep-security/aws-wafをgit cloneして、AWSリソースとの統合までを実演していました。
このスクリプトは2016年8月25日現在開発中とのことで、仕様が変わる可能性はあるのですが、dryrunもできて良いと思いました。

AWS運用時に気をつけておくべきセキュリティのポイント

登壇者は株式会社ターン・アンド・フロンティア　フェローの上平 裕弥氏です。　　

題材はオーソドックスとされる3階層ネットワークでした。ただ踏み台サーバなどのコストがかかり予算に収まらないということで、NATや踏み台サーバなし、LBなしDB同居という構成にする方もいらっしゃるようですが、攻撃を受けるリスクが高いです。
試しにポートを開けてEC2を作りSSHログをtailすると、EC2作成から約30分後には攻撃が始まります。攻撃したIPアドレスは海外のもので、IPの逆引きとその結果の正引きの結果IPが違うので、攻撃と判断できます。
これを防ぐためには、最低現Security GroupsなどでIPフィルターを設定し、sshは鍵認証にする必要があります。
そして、なんと上平氏ご自身がサーバを乗っ取られた経験を解説しました。

• sshした後、派手なことをせずperlスクリプトを設定
• スクリプトは自身を削除しプロセス名を変更して偽装
• /var/log/以下をunlinkし痕跡をなくす
• IRCでサーバの情報を外部に送信

動作事例の動画では、このスクリプトを使って攻撃されている様子が発表されてました。　

攻撃はこれだけではありません。bashの脆弱性(shellshock)もあります。UAに脆弱性を付くコードを設定して、cgiへの攻撃が行われる様子が解説されました。

次はSQLインジェクションです。脆弱性を持つ簡単なwebアプリケーションへ攻撃されている様子と、SQLインジェクション自体の解説がされました。

最後にXSSです。セッションIDが表示される様子が実演されました。

これらの攻撃にどのように対処するかというと、

• AWS Inspectorで安価に診断($0.30/250回)
• AWSとの連係がしやすいDeepSecurityで行動な防御
• awslogs(CloudWatch Logsのエージェント)をyumで入れてログ転送し改ざんに対処
• 公式ドキュメントを読む

まとめ

現在におけるセキュリティの課題と具体的な対策が分かりやすく解説されており、参加してよかったと思います。
「期日までに所定の目標を達成するシステムを作り障害から早く復旧する」ということはもちろんですが、セキュリティについてもより一層勉強していかなければと思える、良い勉強会でした。