Security-JAWSにAWSJ酒徳さん、NRIセキュア大島さん、F5牧田さんが登壇
たかがアカウント、されどアカウント、AWSでの運用ベストプラクティスは？
2017年09月27日 07時00分更新
Amazon Web Services（AWS）とセキュリティをテーマに活動している「Security-JAWS」が2017年8月24日に実施した第6回勉強会のレポート。第三弾では、AWSの基本「アカウント」を巡るセッションの内容などを紹介する。
マルチアカウントでカオスに陥る前に「ベースライン」の適用を
アマゾン ウェブ サービス ジャパンの酒徳知明さんは、「DevSecOps in AWS Multi-Account」と題するセッションを行なった。プレゼンテーションのテーマは、DecSecOpsの前提となる「マルチアカウントストラテジー」だ。
アマゾン ウェブ サービス ジャパンの酒徳知明さん
AWSを一つのアカウントだけで運用している企業はおそらく少数派。サービスごと、プロジェクトごとに複数のアカウントを使い分けている企業が大半ではないだろうか。酒徳氏が勉強会の来場者に尋ねても、ごく少数の例外を除いてほとんどがマルチアカウントで運用している状況だった。だが「とりあえずアカウントは複数持っているが、誰がどのアカウントを使っているのか、作られたアカウントに対してうまく統制をとり、セキュアに運用できているかというと、必ずしでもそうではない」と酒徳さんは指摘し、AWSが提唱しているベストプラクティスを元に、マルチアカウント運用のベースラインをどのように作るべきかを解説した。
AWSを利用する用途はさまざま。マルチアカウントを採用する理由も、ガバナンスやセキュリティ上の理由にはじまり、「課金を分けたい」「事業部ごとに分けたい」といった具合にさまざまだ。AWSでは「タグ」を用いてある程度リソースを分け、管理することも可能だが、完全に分けたいとなるとやはり別のアカウントを使わざるを得ない。こうして別々のアカウントを作っていくと、「誰がどのアカウントを使っているかが分からない」といった事態に陥る。
酒徳さんはこの状態に対し、IAM（Identity Access Management）ユーザーをどんどん追加するのではなく、「ロール」機能を活用し、そのつど必要な権限を借りにいく（＝引き受ける、Assumeする）ことで、ガバナンスを確保しながら運用やセキュリティの負荷を軽減できると説明した。
ユーザーやグループの作成などが行なえる「IAMアカウント」は、AWS運用に不可欠だ。意識せず運用していると、ついつい用途ごと、プロジェクトごとにIAMアカウントから新たなユーザーを作ってしまいがちだが、15種類あるIAMに関するベストプラクティスの1つでは「IAMユーザーを持つアカウントはなるべく絞るべし」とされている。というのも「AWSではIAMユーザーのアクセスキーとシークレットアクセスキーをセキュリティ部門が管理し、定期的にローテーションするよう推奨している。ユーザーが増えれば増えるほど、その管理負担は増大する。複数のアカウントがあり、複数のIAMユーザーがいるということは、複数のアクセスキーとシークレットキー（クレデンシャル）が存在しているということ。そらすべてをきちんとローテーションできるかというと難しい」（酒徳さん）。最悪の場合、それが漏れて悪用されるリスクもある。
アカウントそれぞれでIAMユーザーを作る代わりにAWSが推奨するのが、IAMが提供する「ロール」機能の活用だ。IAMユーザーを作るアカウントは1つに絞り、集中的に管理して確実にキーローテーションを行いつつ、残りのアカウントはすべてロールで管理する形だ。たとえば、子アカウントがEC2を立てたいと考えた場合、親アカウントにロールを借りにいく（＝AssumeRole）。親アカウントは一時的に使えるキーを貸し出し、それを用いて構築・デプロイを行う仕組みだ。そのつどIAMユーザーを作る必要はない。
「IAMの強さは『ロール』にある。一時的にしか使えないテンポラリのトークンを発行し、貸し出す『AssumeRole』をAWSがマネージドの形で提供している。これがすべてのベースになっている」（酒徳さん）
酒徳さんは、マルチアカウントに関するこうしたベースラインを理解した上で、セキュリティのベースラインを当てていくことが重要だと説明した。そこで活用したいのが、CloudFormationのテンプレートだ。これを用いれば、例えば「常にCloudTrailがオンになっている」「S3アクセスロギングやバージョニングが常にオンになっている」といった設定を用意に配布できる。さらに、CloudWatch Eventsを組み合わせれば、機能が無効化されるといった変更が子アカウント側で発生すると通知することも可能だ。APIゲートウェイを介してSlackに通知することもできるという。
これまで、こうした仕組みを作るのはひと苦労だった。酒徳さん自身はStep Functionsを組んで実現していたというが、最近のアップデートで登場したCloudFormationのスタックセットによって、作業が大幅に簡素化できるという。
リスト型攻撃からAWSのアカウントを守る多層防御
AWS利用の基本は「アカウント」だ。もしアカウントが他人に乗っ取られ、悪用されれば、大きな被害が生じることになる。NRIセキュアテクノロジーズ（NRIセキュア）の大島修さんは、「AWSで実践するリスト型アカウントハッキング対策」と題するセッションで、AWSに限らず、さまざまなWebサービスで課題となっているこの問題に切り込んだ。
NRIセキュアテクノロジーズの大島修さん
大島さんは、ブルートフォースやリスト型攻撃、ソーシャルハッキングといったさまざまな方法によってアカウントのハッキングが可能であることを説明。特にリスト型攻撃は「成功率もそこそこあり、課題になっている。しかもリスト型攻撃の元になるIDやパスワードの漏洩は毎日どこかで起こっている」（大島さん）のが現実だ。
では、この攻撃にどう対処すべきだろうか。大島さんは「やはり多層に防御する必要がある」と説明した。第一の層はAWS WAFによるレートリミットだ。特定のURLに対して一定時間内にしきい値を超えるアクセスがあれば、ELBやCloudFrontなどにひも付け、ブロックする仕組みだ。
二つ目の層はAWS WAFとLambdaを組み合わせる方法だ。特定のIPアドレスから高頻度でアクセスがあれば、そのIPアドレスをLambda経由でAWS WAFのブラックリストに自動的に追加するやり方だ。
「それでもやはり、しきい値の探り合いになったり、ボットネットを用いて少しずつ異なるIPアドレスから攻撃するパターンもあり、攻撃者とのいたちごっこになってしまう」（大島氏）。そこで注目したいのが、複合的な「コンテキスト」を組み合わせて不正なユーザーや攻撃者を識別する方法だ。アクセスしてきた端末の属性や地理的属性、利用時間、ページ遷移の特性などを解析し、不正なアクセス、危ないアクセスアクセスを見つけ出すやり方で、NRIセキュアもそのための製品「Uni-ID Identity Fraud Detection」を提供している。
そして最後の砦がハードウェアトークンやソフトウェアトークン、SMSなどさまざまな手法を組み合わせた多要素認証の強化だ。大島さんは「ただ、機械的に毎回多要素認証を求めるとユーザービリティが悪化するため、リスク検知と組み合わせるのが望ましい」と述べ、使いやすさとセキュリティの両立が重要だと指摘。一例として、Uni-ID Identity Fraud DetectionをCognitoと連携させ、AWS向けにリスクベース認証を実現するやり方もあるという。
Uni-ID Identity Fraud DetectionをCognitoと連携
BIG-IPの機能を使い倒してS3バケットへのアクセスをセキュアに制御
「BIG-IPをVPCエンドポイント的に使ってみた ～F5のAWS関連アップデートもあるよ」では、ロードバランサやWAFといったさまざまな機能を提供するネットワーク機器「BIG-IP」を提供するF5ネットワークスジャパンの牧田延大さんが、BIG-IPを用いてVPCのプライベートサブネットから同じリージョンにあるAmazon S3バケットに安全にアクセスする方法を紹介した。
F5ネットワークスジャパンの牧田延大さん
すでに「VPCエンドポイント」の登場によって、NATやインターゲットゲートウェイを介さずとも、S3への安全なアクセスを楽に行えるようになった。BIG-IPの機能は、このVPCエンドポイントと「かぶる部分がある（笑）」と牧田さんは述べつつ、BIG-IPとiRulesを活用するとさらに柔軟で高度なアクセス制御を行なえると説明した。
具体的には、httpとhttpsといったスキームの変換やS3のヘルスチェック、アクセス先URLとローカルホストパスの変換が可能だ。またレスポンスのヘッダーの中からセンシティブな情報をサニタイズしたり、IAMユーザーのアクセスに対して、一定時間しか有効にならない「Pre-Signed URL」を発行することで、よりセキュアなアクセスが可能になるという。Node.jsインスタンスのランタイムを実行できる「iRules LX」を組み合わせれば、BIG-IPからLambda的にAWSのSDKを呼び出し、より複雑な処理を行なうことも可能だ。BIG-IPが元々備えるキャッシュやTCPコネクションの多重化によってパフォーマンスを高める効果も得られる。
牧田さんはデモンストレーションを交えながら、「BIG-IPを使って、NATインスタンス兼VPCエンドポイント的でしかもAmazon CloudFront的な使い方ができる」と説明した。
