#技術書典 に出展する『AWSの薄い本 IAMのマニアックな話』はこんな本

たびたびTweetしておりますが、2019年9月22日の技術書典7に、『AWSの薄い本　IAMのマニアックな話』という本を出展します。名前の通りAWS本ですが、IAMだけを取り扱っています。初の同人誌を引っさげて、技術書典デビューします。

IAM本の目的

　書いた本はIAMの特化本ですが、何故IAMと聞かれるのでここに書いておきます。AWSが不正利用されて100万円の請求が来たというようなニュースが、たまにネットを駆け巡ることがあります。原因の多くがIAMのアクセスキーをGitHubに誤ってコミットしてしまい、そのキーを不正利用されたケースです。そういった事態を防ぐために正しくIAMを知って貰いたいのです。

　IAMは、AWSの利用権限を管理する極めて重要な機能です。AWSには多種多様な機能があり、IAMはそれに応じて様々な記述方法で権限を設定できるようになっています。その分設定項目が多く、IAMは難しいと印象を持っている人も多いのではないでしょうか。また、ある程度IAMに習熟した人にとっては、他の人かどのような方針でIAMの権限設計をしているか気になるという人も多いでしょう。そんな要望に応えるべく、私の考えるIAMのベストプラクティスをまとめてみました。

対象読者

想定読者としては、次のような人たちと考えています。

• AWSアカウントのルートユーザーでAWSを使っている人
• IAMユーザーで使ってるけど、Administrator権限しか付与したことがない人
• 企業内でAWSを導入済みで、異なるロールの様々な人にIAMの権限を振り分ける必要がある人
• お一人様AWS利用だけど、AWSを不正利用されないようにちゃんとIAMを使いたい

つまりは、初心者からそれなりに使い込んでいる人まで、満足頂けるような内容目指しています。

IAM本を読むことで得られること

それでは、読んだらどうなるのでしょうか？

• IAMの機能に関する一通りの知識と、権限設計のノウハウ
• 設計する上でのセキュリティの考慮点と運用について
• IAMマニアの称号

IAMに関する一通りの知識はつきます。また、それ以上にIAMを設計する上での考え方というのが身につくことを目的に構成しています。あと、自分の机の上に置いておいたらIAMマニアと呼ばれるような本になったのではと思います。

IAM本の構成

全部で10章構成です。

第1章 AWS と IAM
第2章 IAM の機能
第3章 IAM チュートリアル
第4章 IAM ポリシーのデザインパターン
第5章 IAM グループのデザインパターン
第6章 IAM とセキュリティ
第7章 IAM の運用
第8章 IAMとCloudFormation
第9章 IAMのテンプレート集
第10章 IAM以外のAWS サービスの活用

１〜３章

１〜３章で、IAMの基本的な部分が理解できるようになっています。特にチュートリアルは、次のように実践的なことを手順とその意味を含めて解説しています。ここをやるだけでも、そうとうにIAMの理解が進みます。

1. IPアドレス制限をするカスタマー管理ポリシーを作成する
2. グループを作成する
3. 作成したグループに、全サービスの参照権限とIPアドレス制限をしたカスタマー管理ポリシーを紐付ける
4. IAMユーザーを作成し、作成したグループをアタッチする
5. クロスアカウントロール（IAMロール）を作成し、作成したIAMユーザーからのみスイッチできるようにする

４〜５章

４章と５章が、IAMの設計の考え方です。具体的な設計ではなく、設計の考え方です。ここをちゃんと読んで理解していただければ、自分で設計する際の指針が培われます。

６〜９章

６〜９章が実践編です。セキュリティと運用という２つの大きなテーマを元に、具体的なポリシーとその意味の解説をしています。紹介しているケースもわりと現実的な内容になっています。また、MFAやIP制限、或いはアクセスキーをどうしたら良いのかなど、一度は悩む部分に対して回答しています。９章でCloudFormationによるテンプレートを用意しているので、それをそのまま使えばIAMに関する設計開発の手間が省けるようになっています。

目次詳細

目次は、こんな感じです。雰囲気伝わりますでしょうか？

はじめに
　本書の目的
　対象読者
　本書で得られること
　お問い合わせ先
　免責事項

第1章 AWS と IAM
　1.1 認証と認可
　1.2 AWS のアカウント種類
　1.3 AWSアカウント
　1.4 IAM ユーザ
　1.5 注意とお願い

第2章 IAM の機能
　2.1 IAM ユーザー
　2.2 IAM グループ
　2.3 IAM ポリシー
　2.4 IAMロール
　2.5 パーミッション・バウンダリー
　2.6 IAMの機能のまとめ
　【コラム】　AWSアカウントとIAMの関係

第3章 IAM チュートリアル
　3.1 IAMポリシーの作成
　3.2 IAMグループの作成
　3.3 IAMユーザーの作成
　3.4 クロスアカウントロールの作成
　3.5 チュートリアルのまとめ

第4章 IAM ポリシーのデザインパターン
　4.1 ホワイトリスト・パターン
　4.2 ブラックリスト・パターン
　4.3 ハイブリット・パターン
　4.4 IAMポリシーのまとめ
　【コラム】　最小権限の探求

第5章 IAM グループのデザインパターン
　5.1 複数グループに所属
　5.2 グループ内に複数ポリシー
　5.3 IAMグループのまとめ
　【コラム】　IAMグループの階層構造について

第6章 IAM とセキュリティ
　6.1 IAMベストプラクティスの遵守
　6.2 ルートユーザーを使わない
　6.3 IAMに関する権限付与
　6.4 Lambdaのリソースベースの権限
　6.5 インターネット公開系の権限
　【コラム】　ec2の権限範囲の問題
　6.6 VPC内からのアクセス
　6.7 アクセスキーの原則禁止
　6.8 CapitalOneの情報流出事件に思うこと
　6.9 IAMとセキュリティのまとめ
　【コラム】　IPアドレス制限の是非とゼロトラストセキュリティ

第7章 IAM の運用
　7.1 IAMの運用の目的
　7.2 役割と責任範囲の明確化
　7.3 AWS アカウントの管理
　7.4 IAM ユーザーの管理
　7.5 アクセスキーの管理とCLI
　7.6 MFA 未利用時に権限を制限し、MFA 利用を促す
　7.7 マルチアカウントでの運用
　7.8 運用のまとめ

第8章 IAMとCloudFormation

　8.1　IAMとCloudFormation
　8.2　CloudFormationの分割単位・依存関係
　8.3　CloudFormationとIP制限
　【コラム】　ライフサイクルで考える

第9章 IAMのテンプレート集
　9.1 共通系ポリシー
　9.2 管理者グループ
　9.3 ネットワーク管理者グループ
　9.4 開発者グループ
　9.5 オペレーターグループ
　9.6 経理担当者グループ
　9.7 お一人様AWS
　9.8 IAMのテンプレートのまとめ

第10章 IAM以外のAWS サービスの活用
　10.1　AWS Organizations(組織アカウント)
　10.2　AWS CloudTrailとAWSConfig
　10.3　Amazon GuardDuty
　10.4　AWS ControlTowerとAWS SecurityHub
　10.5　今後のAWS運用について

開催日時と会場・ブースの場所

2019年9月22日（日曜日）　11:00〜17:00
池袋サンシャイン3階　展示ホールCのお２６です
この辺です

サークルチェック

　最後にお願いです。技術書典では、サークルチェックという機能があります。出展者は、このチェック数をみて、当日どれくらい売れそうか判断します。同人誌なので当日売れないと販売の機会はなかなか無いです。そのため、印刷部数はシビアに考える必要があります。もしこのエントリーをみて興味を持ち当日来場される方は、ぜひチェックリストに追加をお願いします。チェック数が目安になるので、出展者側としては大変助かります。

　↓のサークル詳細ページから追加できます

techbookfest.org

オンラインでの販売

BOOTHでPDF形式で販売中です。
takuros.booth.pm

また物理本で在庫として残った分は、BOOTHで委託販売します。入庫待ちということで、9月末くらいに販売開始できるとおもいます。
Kindleについては、ePubの調整が必要なので今しばらくお待ち下さい。

See Also:
技術書典7に出展します

マルチAZ構成で単一AZの障害の影響を受けるのは何故か？

昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。

前提としてのELBの実装（の予想）

マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。

blog.takuros.net

旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが、それほど間違っていないのではないかと思っています。

マルチAZ構成で単一AZ障害の影響を受けるケース

上記のアーキテクチャの予想が正しいと仮定すると、単一AZ障害がマルチAZ構造に影響を及ぼす可能性が見えてきます。2つのAZを利用したELBを利用したマルチAZ構成の例で考えて見ましょう。AZ内には、それぞれ1台づつインスタンスがあるものとします。

ELBのファクターを考慮しないケース

まずELBのファクターが無い状態で片方のAZで障害が発生したとしたら、取りうる値は次のとおりです。ELBのヘルスチェック機能で障害AZの方に振り分けなければサービスが継続できますね。これが通常のマルチAZの考え方です。事前にテストする場合、片方のインスタンスを落とすか通信できなくしてテストすると思います。その場合も、ヘルスチェックのおかげで正常なサーバに振り分けられます。

正常AZ　インスタンス　○
障害AZ　インスタンス　☓

※今回はAZが全滅した訳ではないので、障害AZ内に生きているインスタンスがある可能性はありますが、単純化のために無視

ELBのファクターを考慮するケース

次にELBのファクターを入れて考えてみましょう。先程の組み合わせは、次のように変わります。今回は便宜上、障害AZ内に生きてるインスタンスと死んでいるインスタンスがあるという前提にしています。次のような組み合わせになります。

正常AZ　ELB　○　インスタンス　○
障害AZ　ELB　○　インスタンス　☓
障害AZ　ELB　☓　インスタンス　○
障害AZ　ELB　☓　インスタンス　☓

マルチAZで問題が発生するケースは、ELBが☓の場合だったのではないかと推測しています。もっと言うと、ELBが中途半端に壊れかけの場合だった可能性が高いです。そうなるとDNSにより障害が発生しているELBに振り分けられ、問題になると思います。

この問題の難しいところ

仮定を置きまくっていますが、シングルAZの障害がマルチAZ構成に影響を与える理由としては上記と推測しています。そして、この問題の難しいところとしては、この事象を正確に検知する方法がないということです。CloudWatchで ELB 5XXsのメトリクスを見ていると、ELB全体として何か問題が起こっていることは解りますが、個別のELBインスタンス（仮称）の問題を検知することができません。これが対応を難しくしています。

どういう構成にしておけば良いのか？

　それではどういう構成にしておけば良いのでしょうか？ちまたでは、マルチリージョンやマルチクラウドなど勇ましい話を聞きますが、殆どのケースで費用対効果に合わないと思います。比較的簡単にコストもほぼ変わらないで実現する方法としては、2AZではなく3AZ構成にすれば良いと考えています。そして、障害を起こしたAZを切り離します。
　今回の分析（妄想）で、AZ内のELBインスタンス（仮称）が問題を起こしており、ユーザー側の操作でそれをどうにかすることは出来ません。であれば、ユーザー側が対処できる方法として、3AZ構成にして問題があったら1つのAZを切り離すという方法が現実的です。実際にそのような対応をされて問題が収束したというケースがあったようです。

でも、その前に

　じゃぁ3AZ構成が有効として、障害が発生した時にすぐに対応すべきなのでしょうか？これも現実的にはNoです。もし上記のような対応をするのであれば、設計段階で3AZから2AZへの縮退稼働を織り込んでおく必要があります。そして、切り替え手順（スクリプト含む）・訓練を含めて事前に共有しておく必要があります。また、切り離しの判断基準や2AZから3AZへの復帰手順も必要ですね。
　それなしにぶっつけ本番で試すのは無謀です。2次被害の可能性も出てくるので、それであればAWSを信じて待つというのも正しい選択肢です。

まとめ

　今回の障害で、私自身もいろいろ知見を得られました。2018年に東京リージョンに事実上の3AZ目が使えるようになったので3AZ設計についても考えようかと思いつつも、具体的な設計に落とし込んでおりませんでした。今回のケースを考えると、もう少しアーキテクチャについて考えていかなければと反省点しています。ただピンチはチャンスです。Twitterのタイムラインを見ていても、皆さん色々な考察や対処法を考え出しているので、日本のAWSを使ったシステムももう一弾進化しそうな気配を感じています。みんなで頑張って、より良いシステムを作っていきましょう！！

　ちなみに今回のケースも、マルチAZ構成にしておけば影響が小さくなったのは間違いないと思います。また言及していませんが、RDSやCloudFrontなど他の要因もあったと思います。

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

BOOTHで電子書籍販売中！！
takuros.booth.pm

AWSのAZの割り当ては、アカウントごとに違うという話

　先週の金曜日（2019/8/23）に発生したAWSの東京リージョンで大規模な障害が発生しました。障害の内容は、一つのAZで空調設備の問題からEC2インスタンス並びにEBSに問題が発生したという事象です。詳細についてはAWSから発表があるので、そちらをご参照ください。
aws.amazon.com

　障害の最中にTwitterのタイムラインを見ていると、単一AZ障害ではなく複数のAZで障害が発生しているのではないかという観測が多く見られました。障害としては、AWSの発表通り単一AZ障害です。では何故多くの人に勘違いされたのでしょうか？理由は2つあります。

• AZの割り当ては、アカウントごとに違うという事が知られていない
• マルチAZ構成にしていても、単一AZの障害の影響を受ける

ここでは前者のAWSアカウントの割り当ての話を説明します。

あなたが見ているap-northeast-1aは、私が見ているap-northeast-1aと違うかもしれない

---

　障害発生中に下記のようなTweetをしたところ、知らなかったという反応を沢山いただきました。これを、もう少し説明してみます。

現在のAWSの障害は、AZの中の一つ（apne1-az4）で発生してる模様。大切なポイントなのだけど、アカウントごとにAZの割当は違う。なので、とあるアカウントだと1aで問題が発生し、別のアカウントだと1cで発生というのがありうる。ということで、ご留意ください。

— Takuro SASAKI (@dkfj) August 23, 2019

　実はAWSのAZのマッピングは、アカウントごとに異なっています。あるアカウントのap-northeast-1aのデータセンター群は、違うアカウントのap-northeast-1cと同じデータセンター群かもしれないです。そうなっている理由としては、AZごとの利用率の偏りを避けるためだと推測しています。リストの一番最初に出てくる1aをみんなが使うと、AZごとにインスタンス利用数等が著しく偏る恐れがあります。そうならないようにAZのマッピングを変えることで回避しているのでしょう。
　マッピングの違いについては、公式のドキュメントに記載されています。

docs.aws.amazon.com

リージョンごとのアベイラビリティーゾーンの数とマッピングは、AWS アカウント間で異なる場合があります。アカウントで使用可能なアベイラビリティーゾーンのリストを取得するには、Amazon EC2 コンソールまたはコマンドラインインターフェイスを使用できます。詳細については、「リージョンとアベイラビリティーゾーンの記述」を参照してください。

AWSアカウントのAZのマッピングを知るには？

---

　それでは、AZのマッピングを知るにはどうしたら良いのでしょうか？2018年の末くらいに、AZ IDという一意のIDが表示されるようになりました。これを使うとアカウントのマッピングに関わらずAZを一意に識別できるようになります。具体的には、VPCのサブネットの作成や詳細のところに出てくるので、それをご参照ください。

昔はどうやってマッピングを知っていたのか？

---

　ここからは余談です。AZ IDが出てきたことで、簡単にマッピングを知ることができるようになりました。実はこのAZ IDがなくても、マッピングを推測することは可能だったのです。その答えはスポットインスタンスの価格の推移です。スポットインスタンスの価格の推移は、AZごとです。複数のアカウントの価格の推移を突き合わせると、推測できるという寸法です。

※スポットインスタンスの乱高下が、ほとんど無くなってきたなぁという感想

まとめ

---

　VPC Peeringが無い時代は、AZの割り当てが解らなくても余り困りませんでした。今は解るようになっています。ただ、解った所で、それほど気にする必要がないのも事実です。一方で今回のような自体が起きると、知っていないと混乱します。ということで、豆知識として覚えておいてください。ここAWS認定試験で必ず出ないポイントとなっております。試験のポイントについては、オレンジ本をご参照ください。あと、来月の技術書典7に初参加です。よろしくお願いいたします。

　今回すっ飛ばした「マルチAZ構成にしていても、単一AZの障害の影響を受ける」理由と対策については、明日くらいに解説します。

2019年8月27日追記：　続き書きました
マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

BOOTHで電子書籍販売中！！
takuros.booth.pm

Japan APN Ambassador 2019ならびに2019 APN AWS Top Engineersになりました（なってます）

　随分前に発表されてTwitterでも呟いておりましたが、ライフログとしてはこちらの方が振り返りやすいので改めて書いておきます。Japan APN Ambassador 2019ならびに2019 APN AWS Top Engineersに選出されました。周りの方々のご協力に、感謝です。

※NRIの同僚で同じく選出された瀬戸島さんと、AWSの方々との写真です。

Japan APN Ambassador 2019

---

Ambassadorというのは、AWSのグローバルなプログラムで、

世界中のAPN Consulting Partnerから卓越した技術力を持ち、社外への情報発信（セミナーでの発信、Blogや書籍での発信）をしているメンバーが選出されます。

とのことです。日本では今年から制度が始まり14名選出されました。

2019 APN AWS Top Engineers

---

　併せて受賞したなのが2019 APN AWS Top Engineersです。こちらは、社内での活動（案件・人材育成）と社外での活動（発信）を評価するようです。
　なお、併せて受賞と書きましたが、AmbassadorとTop Engineersのエントリーフォームは同じで、先にTop Engineersに選ばれましたよ〜ってメールを貰った後にしばらくして、Ambassadorにも選ばれましたという経緯です。Ambassadorの人が必ずTop Engineersに選ばれているのか不明ですが、おそらくTop Engineersの中から選出されているのかなと思います。

aws.amazon.com

なぜ選ばれたのか？

---

　あくまで推測ですが、私の場合はNRIネットコムという会社の中でAWS事業を推進する立場にあります。そこで、当然様々な案件に関わりますし、人材育成も行っています。特に2018年度は社内の研修講師として、かなりの数の講座を受け持ちました。対外発表面は最近サボっていたのですが、書籍の執筆は継続的に続けており、その辺りが評価されたんじゃないかなぁと思います。

これからどうするの？

---

　今までの活動を評価されたというのは、素直に嬉しいです。とりあえず一発屋にならないように、来年もTop Engineersに選出されるように精進します。あとは、後進の育成ですね。実は社内で私以外誰も応募しておりませんでした。選ばれそうな実力を持った人は社内には沢山いるので、そういった人たちのアピールと対外進出を支援していこうと思います。
　また授賞式の時にAWS相澤さんが「Go Globalの精神で、世界に進出していってください」と話されていました。せっかくなので、今年は日本のみならず世界にもアピールできるような事を考えて実行していこうと思います。出来ることからですけどね。

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

Nature RemoとAmazon Echoの連動で家電操作は、エアコンが便利

随分前に自宅のIoT化ということで、Nature Remo miniを導入しました。構成は割とスタンダードだと思うのですが、Amazon Echo（Alexa）とNature Remo miniを連動させて、居間にあるリモコンで操作できる家電各種と連動させています。

連携させたのは、下記の4台です

・テーブル上のメインの電灯
・エアコン
・テレビ
・ファン付きシーリングライト

利用風景

---

　なかなかイメージがしにくいと思うので、実際の動作の様子を音声で聞いてください。出演者は、私とAlexa（Amazon Echo）とエアコンさんです。

私：　　　Alexa エアコンつけて
Alexa:　　はい
エアコン：温度は28℃に設定されました
私：　　　Alexa エアコンけして
Alexa:　　はい
エアコン：運転を停止しました

　このエアコン、ダイキンのうるるとさららで喋ります。Alexaより喋ってます。買った当初は喋るの意味ないなと思ってたのですが、Alexaと連動させると近未来感が出てきて非常にグッドです。

Nature Remoとの連動に効果を発揮する家電

---

　半年くらい使ってみての感想ですが、Nature Remoとの連動が効果を発揮する家電は次のようなものです。

• リモコンの利用頻度が少ない
• 操作が単純

　我が家では、エアコンとシーリングライトについているファンを回すのに活躍しています。シーリングライトのファンは回すと便利なのですが、そのためだけにリモコンを用意するのが面倒くさくて永らく使っていませんでした。Nature Remoのおかげで再び回りだすようになりました。

意外に連動効果がない家電

---

　一番最初に試して、あまり意味がなかったなと悟ったのは電灯・ライトです。居間の構造上、入り口すぐの時にオンオフのスイッチがあり、必要な時はそれを操作した方が早いです。またスイッチがオフの状態でAlexaで操作しても、当然ながら電気はつきません。もしこれが寝室だったら、布団に入って寝る前に本を読んで、そのまま布団から消すといった効果があるかもしれません。が、今の所、寝室への導入はしておりません。

　そして同じく効果の薄い連動が、ルンバです。IT家電の代名詞の一つ、ルンバさんもNature Remoとの連携機能があります。ただ我が家の状況的には、連動してもあまり意味がないなということで解除しています。なぜならば、散らかし放題の2人の幼児がいる我が家では、ルンバさんを動かす前に部屋の片付けが必要です。その労力を費やした後にルンバさんの稼働となるわけですが、そこの部分だけ音声にしてもあまりありがたくないなぁというのが実感です。ちなみにルンバさん、任意の時間に掃除してもらうより、決まった時間に動くように設定しておいて、その前に強制的に片付けざるを得ない状況にする方が効果的ですよ。

テレビとの連動はどうなの？

---

　よく聞かれるのが、テレビとの連動。我が家ではリアルタイムのテレビを見ることが殆どありません。録画済みのものや、Netflix等のオンデマンドTVです。なので、Alexaさんで操作するには少し無理があります。結果的に使ってるのは、テレビを消す時だけです。ただ、これはこれで便利です。テレビを見るのを止めない子供たちに、Alexaさんは無慈悲にテレビを消してくれます。もちろん怒りの矛先は私にきますが。

まとめ

---

　Nature Remo miniは5〜6千円くらいで買えるので、スマートスピーカーを持っている方は是非ご検討をお勧めします。Amazonや家電量販店でも、定期的に安売りしているので時期見計らって買ってみてはいかが？ちなみに私は使っていないのですが、インターネット経由で家電の操作もできます。エアコン消したかなといった心配も、Alexaアプリから確認できるようになります。

Nature Remo mini 家電コントロ-ラ- REMO2W1

Echo Dot 第3世代 - スマートスピーカー with Alexa、チャコール

Capital Oneの個人情報流出事件に思うこと

　2019年7月末に、米大手金融機関であるCapital Oneが不正アクセスによる1億人を超える個人情報の流出を発表しました。規模もさることながら、Capital OneはAWSから何度も事例に取り上げられるような先進的な企業だったので、個人的にかなり衝撃を受けました。また、攻撃手法についても、従来の単純な設定ミスを狙ったものではなく、より一歩踏み込んだ攻撃という印象を受けました。

攻撃手法

---

　攻撃手法については、piyologさんのSSRF攻撃によるCapital Oneの個人情報流出についてまとめてみたが非常に解りやすいので、まずはご参照してください。
piyolog.hatenadiary.jp

　攻撃手法を簡単にまとめると、WAFの脆弱性を利用してIAM Roleのクレデンシャル情報を取得し、それを手元から利用して情報を取得したという形です。piyologさんの図を、再描画させて貰いました。

どうすれば良かったのか？

---

　情報流出の一次的な原因としては、WAFです。セキュリティ製品については、もう独自の運用でカバーできる範囲ではないので、AWS WAF等のマネージド・サービスもしくは、専門の会社が提供する製品を利用するのがあ良いでしょう。ただ、あくまでWAFについては一次的な原因で真の問題については、別のところにあると思います。それは、不用意に大きな権限を持ったIAM Roleを利用した点にあります。

　対策としては、2点考えられます。

IAM Role側の対策

• 特定のS3 Bucketのみ接続できるようにする
• 必要なアクション（例えばPut）のみ権限を付与する

S3 Bucket側の対策

• Bucket Policyでec2 instanceが属するVPCからのみ接続できるように制限する

　S3に格納する情報は、非常に重要なものが含まれるケースがあります。その場合、IAMポリシーのみの設定のみで防御するのは危険です。必ずBucket Policyでも制限を加えるべきです。Bucket Policyの制限は強力で、どのようなIAMの権限を与えていても、ポリシーに合致していないと見ることはできません。

悩ましい点

---

　上記の設定をすれば今回の事件は防げたと思います。一方で、IAM Roleを付与していたec2がgetとput両方の権限が必要であった場合、ec2からの操作で情報流出の可能性はあったでしょう。また、それ以前に全てのAWSの設定のうちで、1箇所だけ設定を間違っていただけで、このような甚大な被害が発生する可能性があるのです。Capital Oneがどれほどの規模のシステムか具体的に知りませんが、おそらくかなり巨大なシステムでしょう。AWSアカウントやIAMロール、S3バケットの数は無数にあると思います。上記のような個別防御の他に、様々な観点で防御する必要があるでしょうね。

感想と宣伝

---

　AWSのセキュリティを考える上で、IAMに対する理解はかなり重要です。ということで、IAMに特化した150ページほどの薄い本を2019年9月の技術書典7に出展予定です。上記のような設計の考え方、具体的なポリシーの実例をドドンと挙げています。出展については、こちらを参照してください。
　また書いているうちに確信したのですが、IAMの防御は基本だけどそれのみでは、もはや足りません。そのうちどこかで、その他のセキュリティについても書こうと思います。

追記：上記の話を盛り込んだIAM本、書きました！！
BOOTHで電子書籍販売中！！
takuros.booth.pm

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

技術書典7に出展します

　Twitterで呟きましたが、9/22（日）に開催される技術書典に出展します。
techbookfest.org

出展内容

---

　とりあえず出すことを決定してるのは、AWSのリソースに対する認証認可の機能であるIAMに関する本です。おそらく100ページから150ページほどになると思いますが、その中でひたすらIAMに関することを取り扱います。商業誌だと1テーマでこれだけ書くのは厳しいので、技術書典ということで好きに書かせてもらいます。

なぜ出展するのか？

---

　商業誌より儲かりそうだからという邪な考え方もあるますが、自由度の高さが魅力です。あと、Kindle等で直接出版をいつかしてみたいという夢を数年前から持っておりました。が、締切がないと全く進まないので、無理やり締め切りを作るために技術書典さんのイベントを利用させて貰いました。

目次（案）

---

　取り扱うテーマとしては、次のような感じです。既に5章までは書いています。書いているうちに多少追加削除していくとは思うので、ご愛嬌ということで。

第1章　AWSとIAM
　1.1 認証と認可
　1.2 AWSのアカウントの種類
　1.3 AWSアカウント
　1.4 IAMユーザー

第2章　IAMの機能
　2.1 IAMユーザー
　2.2 IAMグループ
　2.3 IAMポリシー
コラム　AWS 管理ポリシーとカスタマー管理ポリシーの使い分け
　2.4 IAMロール
　2.5 パーミッション・バウンダリー
　2.6 IAMの機能のまとめ
コラム　AWSアカウントとIAMの関係

第3章　IAMチュートリアル
　3.1 IAMポリシーの作成
　3.2 IAMグループの作成
　3.3 IAMユーザーの作成
　3.4 クロスアカウントロールの作成

第4章　IAMポリシーのデザインパターン
　4.1 ホワイトリスト・パターン
　4.2 ブラックリスト・パターン
　4.3 IAMグループを利用したハイブリット・パターン
　4.4 IAMポリシーのデザインパターンのまとめ
　コラム　最小権限の探求

第5章　IAMグループのデザインパターン
　5.1 複数グループに所属
　5.2 グループ内に複数ポリシー
　5.3　　IAMグループのデザインパターンのまとめ
　コラム　グループの階層構造について

第6章　IAMとセキュリティ
　6.1 IAM権限付与で守るべきポイント
　6.2　　AWS アカウント(ルートユーザー)を使わない
　6.3 IAMに関する権限付与
　6.4 Lambda のリソースベースのポリシーに注意
　6.5 インターネット公開系の権限
　コラム　ec2の権限範囲の問題
　6.6 特定 IP からのアクセスと VPC 内からのアクセス
　6.7　　アクセスキーとシークレットアクセスキーを、原則作らない
　6.8　　CapitalOneの情報流出事件に思うこと
　6.9　　IAMとセキュリティのまとめ
　コラム　IPアドレス制限の是非

第7章　IAMの運用
　7.1 IAMの運用の目的
　7.2 役割と責任範囲の明確化
　7.3 AWS アカウントの管理
　7.4 2要素認証の運用
　7.5 IAM ユーザーの管理
　7.6　　二要素認証のデバイスの運用
　7.7　　アクセスキーの管理
　7.8　　マルチアカウントでの運用
　7.9　　運用の自動化の検討事項
　コラム IAMを制するものがAWSを制する

第8章　CloudFormation
　IAMとCloudFormation
　CloudFormationの分割単位
　コラム ライフサイクルで考える

第9章　テンプレート集
　9.1　Adminユーザ
　9.2　ネットワーク管理者
　9.3　オペレーター
　9.4　開発者
　9.5　監査担当
　9.6　サーバレス開発者
　コラム　IAMの設計で悩んだらベン図を書く

第10章　IAM以外のサービスの活用

この後

---

　今回は同人誌なので、原稿書いた後も全部やる必要があります。印刷の手配とかもやったことがないので、その辺りを1から学びながらやってみます。とりあえず8月中旬には原稿書き上げて、その辺に進みたいなと思います。余裕があれば、もう1冊くらい作りたい気もしますが、他の商業誌の執筆も並行してやってるので難しいでしょうね。あと売り子業、どうしよう？一人でやるのは、無謀ですかね？

書きました！！
BOOTHで電子書籍販売中！！
takuros.booth.pm