プログラマでありたい

おっさんになっても、プログラマでありつづけたい

IAMロールを付与したEC2インスタンスでアクセスキーを利用する

　IAMロールを付与したEC2インスタンスでは、そのロールの権限を利用できます。この機能のお陰で、アクセスキーの必要性はなくなり、より安全に運用することができます。今日のお題は、それでもアクセスキーが必要な場合はどうしたらよいかという点と注意点です。

アクセスキーが必要になるケース

　BOOTHで絶賛販売中のAWSの薄い本 IAMのマニアックな話（※ステマ）を読んたさわらさんから、次のような疑問を頂きました。

【読書RTA】 #技術書典 7で購入した31冊レビュー 【自己最速】

アプリケーション開発で、AWS-SDKを利用する機能を開発するならローカルにIAMのクレデンシャルがないと厳しいような。セキュリティ的には心配なので、環境のVDI化（Workspace）などと組み合わせた対策が要りますかね？

　ここでいうローカルというのは、自分のローカルPCを指していると思いますが、今回はIAMロールを付与したEC2インスタンスで作業するという前提にさせて頂きます。
　AWS-SDKの場合、IAMロールを付与したインスタンス上で作業する場合、IAMのクレデンシャルを設定する必要がありません。SDKの機能で、定められた優先順位に従い、勝手に付与されている権限を取得して利用します。このあたりは、『AWSのアクセスキー・シークレットアクセスキーをプログラムに安全に埋め込む（埋め込まない）方法』で解説しているので、知らない方はぜひ読んでみてください。

blog.takuros.net

　問題は、ツール等の成約でどうしてもアクセスキー・シークレットアクセスキーが必要な場合です。

IAMロールを付与したEC2インスタンスで、アクセスキーを取得する方法

　実は IAMロールを付与したEC2インスタンスでは、メタデータから一時的なアクセスキーを取得する方法があります。
curlコマンドで、ロール名を指定して取得するだけです。

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ロール名
{
"Code" : "Success",
"LastUpdated" : "2019-10-03T22:09:42Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAQZZZZZZZZZZZZZZZ",
"SecretAccessKey" : "PxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"Token" : "クソ長いToken",
"Expiration" : "2019-10-04T04:44:40Z"
}

　この方法でIAMロールの権限を利用できる一時的な認証情報を取得できます。
詳しくは公式ドキュメントの『Amazon EC2 の IAM ロール』の"インスタンスメタデータからセキュリティ認証情報を取得する"のセクションを読んでください。
Amazon EC2 の IAM ロール - Amazon Elastic Compute Cloud

　またこの一時的な認証情報の利用方法については、ClassMethodさんの下記のブログが参考になります。
dev.classmethod.jp

メタデータから取得できる一時的認証情報の問題点

　上記のように簡単に一時的な認証情報を取得できます。あまりに簡単に取得できるので、それはそれで問題じゃないかという話もあります。例えば何らかの脆弱性を利用して、EC2に侵入された場合、ロールに実行場所の制限をしていない場合、クレデンシャル情報を利用して、そのEC2インスタンス以外の場所からでもAWSの操作ができます。実際、Capital Oneの個人情報流出事件は、この方法で取得したクレデンシャルで情報を盗み出した模様です。
　Administrator権限のような強い権限をロールに付与していたら目もあてられませんね。インスタンスにロールを付与する場合、必ず最小権限に絞りましょう。

piyolog.hatenadiary.jp

　個人的には、そのうちメタデータから一時的認証情報の取得の仕方を変えるんじゃないかなぁと思います。GCPの場合だったら、ヘッダー情報にMetadata-Flavor: Googleがないとメタデータを取得できないようになっています。
※この方法だけでは、万全ではないだろうが
インスタンス メタデータの保存と取得  |  Compute Engine ドキュメント  |  Google Cloud

IAMのマニアックな話に追記します

　この辺りの話は、「IAMのマニアックな話」で文章に散りばめてはおりました。しかし、独立した項目として扱っておりません。ということで、電子版の方に追記することにしました。この辺り同人誌だと簡単に変更できて良いですね。技術書典7で紙版で買った頂いた方にも、ダウンロードカードを配布しています。そちらからダウンロードできるファイルについても追記版を取得できるようにしておきます。対応したら、改めて連絡します。
　「IAMのマニアックな話」は、このようなIAMを使う上でのベーシックな考え方からセキュリティ・運用の具体例、テンプレートまでカバーしております。BOOTHで絶賛販売中なので、興味がある方はぜひご検討ください。
※ステマ

takuros.booth.pm

See Also:
#技術書典 に初出展。AWSの薄い本　IAMのマニアックな話を書きました
#技術書典 に出展する『AWSの薄い本　IAMのマニアックな話』はこんな本

執筆のテーマ選びについて #技術書典 参加に寄せて

　前回、 技術書典で刷り数を決める際に考えてたことをまとめました。刷り数は最後の段階なので、今回は一番最初に考えないといけないテーマについて書いてみます。多分、テーマは技術書を作る上で一番重要で、テーマが決まるとほぼ自動的に読者数が決まります。じゃぁ、そこをどう考えて戦略たてるかという話ですね

技術書の市場規模とカテゴリの話

　専門書と呼ばれるジャンルの本は、市場規模が予め決まっています。技術書もその一つで、技術を学ぼうとする人しか読みません。日本のITエンジニアはおおよそ100万人弱で、恐らくその中で自分で技術書を買う人は半分もいないでしょう。そして、一口にITエンジニアといっても、その中では細分化されています。インフラエンジニアやフロントエンジニア、或いはネットワークエンジニアといった区分があります。実際には更に細分化されるし、レベルによってピラミッド構造になっています。つまりAWSで日本語でどんなに売れる本を書いたとしても、100万冊売れることは絶対ないのです。

和集合と積集合

　最初から夢のない話からスタートしましたが、それでは出来るだけ多くの読者に届くにはどのようにすれば良いのでしょうか？1つ目の戦略としては、隣接する分野の読者を呼び込むことです。例えば、AWSをテーマにしたとしたら、アプリエンジニアにも読んでほしいといったケースですね。うまくいくと次の図のように和集合となり、２つのカテゴリーの読者からも読まれるようになります。

f:id:dkfj:20190930003235p:plain

　問題は、これが上手くいくかどうか。失敗するとどうなるかというと、次のように積集合になります。つまり、AWSとアプリを両方ともやる人だけが読むという本になります。そして、その可能性の方が高いです。

f:id:dkfj:20190930003420p:plain

　という事で、当たるとホームランだけど、三振の可能性が高いというのが2カテゴリーにまたがる本です。

カテゴリー内で、ニッチなテーマ

　では、逆にヒットを打てる可能性が高い戦略は何でしょうか？それは、カテゴリー内で、特定のテーマに特化した書く方法です。AWSであれば、その中に多くのサブカテゴリーを内包しています。サブカテゴリー一個一個の需要は小さいので、一般的な商業誌では取り上げづらいです。一方で、既にAWSを利用しているという人にとっては、広く浅い情報より一つのテーマに特化した方がありがたい場合もあります。その場合、多少値段が高くても買うという判断になります。

f:id:dkfj:20190930005238p:plain

　同人誌はこのニッチなテーマと相性がよくて、技術書典で頒布されている多くの本がこの形式なのではないでしょうか？今回、私が書いたIAM本もここを狙って書いています。ちなみにAWSは機能が多いので、この形式で書きやすいです。私自身、深堀りしたいテーマとして、次のようなものがあります。

  • Step Functions
  • Cognito
  • AWS Organizations
  • S3 + Athena
  • GuardDuty

　自分一人で書いていても尽きることがないので、手分けして書いていこうかなと考えています。

市場を広げる本

　本のタイプとして、実はもう一つあります。それは、市場を広げるタイプの本です。手前味噌な事例で申し訳ないのですが、昔クローラー・スクレイピング本を書いた事があります。クローラーを必要とするエンジニアは少ないと思いつつ、クローラーという手法はエンジニア以外にも役に立つだろうと思っていました。そういたら、上手いことあたって、マーケティングをしている人や、統計学でデータを集めている人たちにも一定数の支持を受けることができ、クローラー本としては予想外の売れ行きとなりました。

f:id:dkfj:20190930011853p:plain

　上記については、違うカテゴリーを呼び込むという意味では和集合と似ています。が、こちらは、2つの分野にまたがるのではなく、他分野の人を呼び込むという手法です。これは上手くいくと非常に多くの読者を呼び込めます。技術書典でいうと、mochikoさんや湊川さんがこのタイプの本を得意としているのかなぁと思います。商業誌では、「人工知能は人間を超えるか」などが、このタイプだと思います。

テーマごとの母数の見極め

　テーマ選びの手法は何となく理解頂けたと思うのですが、じゃぁそれぞれのテーマの母数はどうやって知るのかという疑問を持つと思います。これについては、私はハッキリとした答えは持っていません。ただ長年ブログや執筆をしてきた経験があるので、何となくの感覚を持っているというのが正直なところです。技術的な内容でバズっても、その後に書いたワインのブログで100倍くらい閲覧数が多かった時は、やっぱりそうよねという感想しか沸かなかったりします。
　なお、ちゃんとした数字を調べようと思うと、統計データや関連分野の本のタイトル数・売れ行きのランキングなどを丁寧におっていけば、ある程度推測は出来ると思います。私は、そこまでしていませんが。

それより大事な事

　ということで、テーマ選びの際に考えていることを連連と並べてみました。同じ労力を掛けて書くのであれば、少しでも多くの人に届いた方が良いと私は考えています。でも、それより大事な事があると思います。
※必要とする人が少なくても重要な事というのは、もちろんあります。そこを狙うのも、もちろん良いと思います。

- 自分が書きたい事を書いて、結果として自分を成長させること
- 一度やってお終いじゃなくて、続けること

　勉強会の発表や同人誌の執筆すると、一番勉強になるのはやった本人なのですよね。対象に対する理解が飛躍的にあがります。ただ、それが一度目で成功するかというと、中々そうはいかないです。では、成功するにはどうすれば良いのか？答えは成功するまで続けることです。技術書典は、小さなコストで挑戦できます。また開催間隔もおよそ半年くらいと短いので、何度も試せます。今回色々な課題が出てきたようですが、私は素晴らしいプラットフォームだと思います。Let's Try!!

出展したAWSの薄い本 IAMのマニアックな話は、BOOTHで購入できます！！
出品以来、BOOTHの技術書典7の新刊ランキングでほぼ一位継続中の模様です。
booth.pm

#技術書典 の生産管理　印刷数の最適化を考える

　先日の技術書典7で、「AWSの薄い本 IAMのマニアックな話」という同人誌を出展しました。技術書典に参加して面白かったのが、どれくらい売れるのかを予想しながら印刷冊数を検討することでした。どういった検討を経て決定したのか、まとめてみました。

２つのパラメーター

　技術書典で考えるべきパラメータは単純に２つだけです。見込み販売数と印刷数です。見込み販売数は、サークルチェック数を中心に類推し、印刷数は自分で決めます。それぞれ、見てみましょう。

見込み販売数

　まず頭を悩ますのが、見込み販売数です。これは自分だけでコントロールできるものでないので、いかに正確に読み解くかが勝負になります。幸い技術書典には、サークルチェックという機能があり、この数字を元にある程度の販売数を見通すことができます。更に、先人たちの知見の蓄積の結果、開催何日前にどれくらいのチェック数だったら、最終的にどこまでいくかの予想のモデルまであります。やぎっちさんが、毎日呟いて頂いて大変参考になりました。ありがとうございます。

　この被チェック数を元に、自身の予想を加えて見込み販売数が決まります。

印刷数

　見込み販売数が解かると、次はいよいよ印刷数の検討です。まず、バックアップ印刷所である日光企画さんの印刷代をみてみましょう。プランは色々ありますが、一番標準であるオフセット・スタンダードフルカラーで考えてみます。

日光印刷のオフセット・スタンダードフルカラー

次の画像は、ボリュームゾーンを書き出したものです。今回、私は124ページで想定で検討しました。
f:id:dkfj:20190928143735p:plain

見るとすぐに気がつくと思いますが、印刷代は冊数に比例しません。冊数が多くなると1冊あたりの単価は顕著に低くなります。

f:id:dkfj:20190928164352p:plain

例えば、124ページ印刷で50冊の場合だと1冊あたりの単価は1,095円ですが、500冊だと236円になります。大量生産すると原価が安くなるということを実感できますよね。これが、技術書典に出展する際の悩みどころであり醍醐味だと思います。

収支シミュレーション

　それでは、印刷数をどう決めれば良いのでしょうか？まずは124ページ前提で、損益分岐点を確認してみましょう。損益分岐点は、売上と費用の額がちょうど等しくなる販売数量です。販売価格を1,000円の場合と、1,500円の場合で検討しています。
f:id:dkfj:20190928165637p:plain

　冊数が少ない場合、損益分岐点となる冊数が多いのが解ります。特に124ページとある程度厚めにしているので、1,000円で売った場合は50冊の場合は全部売り切っても赤字になります。1,500円で売ると損益分岐点も低く利益が出やすくてバラ色に見えます。
　ただ、ここで見えないパラメータとして、値段と売上数に対する価格弾力性です。価格弾力性は、値段の変化に対して売上数がどれくらい反応するかです。下の図でいうと、出来るかで均衡点に近いところで値段をつけると良いです。

f:id:dkfj:20190928170830p:plain

　技術書典の場合、ある種お祭りのような場なので、価格弾力性は低い（値段が変化に対して売上数が変化しづらい）と考えました。なので、思い切って1,500円に設定しています。ということで、売上数は400冊弱と予想し100冊余らせる前提で、500冊印刷することにしました。これだと、100冊売れば損はしないし、予想通り売れれば充分な利益を得ることができます。

収支シミュレーションその２

　今回は1,500円で124ページという前提でしたが、この値はどちらも一般的なパターンではないと思います。次は、1,000円で84ページの場合で考えてみましょう。このケースの収支シミュレーションは次の通りになります。次回参加するとすると、新刊・既刊でサークルチェック数で予測が難しくなるので、その場合に備えての検討です。

f:id:dkfj:20190928165244p:plain

　100冊前後の売上見込の場合で、100冊するか200冊するかが悩みどころだと思います。100冊の場合は印刷代が46,790円、200冊の場合は56,300円とおよそ1万円の差です。この1万円の差をどうみるかですね。100冊の場合の最大利益は53,200円、200冊の場合は143,700円です。利益を最大化するか、損失を最小化するかで決めればよいと思います。私の場合、たぶん200冊刷って余った分は色々なところで配布して活用すると思います。

感想

　はるか昔、学生時代に経済学部だったので、生産管理の授業でこんな事の計算をしてたのを思い出しました。その時は、もっとちゃんとモデルがあったような気がしますが、すっかり忘れてしまいましたがｗ 技術書典に参加することで、このような経験をすることができるのが素晴らしいと思います。またこの後はBOOTHで販売して、マーケティングも学べますね。こちらも色々試しているので、また報告します。

出展したAWSの薄い本 IAMのマニアックな話は、BOOTHで購入できます！！
出品以来、BOOTHの技術書典7の新刊ランキングでほぼ一位継続中の模様です。
booth.pm

2019年9月30日　11:12追記：
テーマ選びの参考に、記事を書きました。対象読者がどれくらいいるのかの見極め方です
blog.takuros.net


See Also:
#技術書典 に初出展。AWSの薄い本　IAMのマニアックな話を書きました
#技術書典 に出展する『AWSの薄い本　IAMのマニアックな話』はこんな本

#技術書典 に初出展。AWSの薄い本　IAMのマニアックな話を書きました

　少し遅くなりましたが、2019年9月22日に開催された技術書典7の参加記です。

サマリー

『AWSの薄い本　IAMのマニアックな話』という本を、1部1,500円で500部用意しました。また、既刊の商業誌を各5冊づつ用意して、1割引で販売していました。また最終的なサークルチェックの被チェック数は、395でした。
f:id:dkfj:20190924055244j:plain

　当日頒布数は451冊で、売上にして67万6千5百円です。またBOOTHでの電子書籍の販売も22日の正午過ぎに開始して、24日の朝6時の段階で114冊、17万1千円売れています。これに対して経費の方は、印刷代他で20万円弱なので大幅に黒字です。準備不足のまま突入しましたが、まずは大成功でした。

当日配布した本については下記エントリーで紹介しているので、ご興味あれば見てください。
#技術書典 に出展する『AWSの薄い本　IAMのマニアックな話』はこんな本

反省点

大成功と言っても、当日出展している中で様々な改善点がありました。次回以降のために記録として残しておきます。

サマリーで本の内容を伝えるポップ

　当日販売していて本の内容・対象をひと目で伝わるポップを用意しておけば、もう少し売上げアップしていた可能性を感じました。当日の時間帯別の販売数の推移をみてください。

時間 売上数 累計販売数
11:00 151 151
12:00 94 245
13:00 82 327
14:00 43 370
15:00 45 415
16:00 36 451

　11時〜13時台の売上は、凄まじく全体の72%をこの時間帯で販売しました。一方で14時以降については、時間あたりの売上は半減しています。店頭に立っていると、客の行動の違いが解りました。11:00〜13:00は、ほぼ事前に買うことを決めてやってきたお客さんです。これに対し、14:00以降は、ブースを巡って本を探しているお客さんです。
　前者は、サンプル誌を読むことなく即買いします。後者は、サンプル誌を読んだり、本の内容を聞いたりして選びます。Twitterやブログで事前の告知をしていたので、前者の方には割とPRも出来て本の内容も伝わってたかと思うのですが、店頭で初めて見た方向けの情報が少なかったかなと思いました。ここは次回に向けての改善点です。

商業誌がスペースを圧迫

　せっかくの機会なので、商業誌も知ってもらいたいと合計6誌、30冊ほど用意しました。1割引で販売していましたが、やはり技術書典でわざわざ買う動機は少なく、12冊しか売れませんでした。もともと売れるとは思っていなかったので売上自体は良いのですが、スペースを圧迫したのは痛手でした。これは本棚か、或いは縦に並べる展示台のようなものを用意すれば良かったかなと思います。
　また唯一売り切れたAWSの認定資格本は、手配ミスで3冊しか用意していなかったです。こちらは12時台で早々と売り切れ、その後に売ってないのと何度も聞かれたので、機会損失していました。技術書典の来場の方の特性上、勉強熱心な方が多かったのかなと推測しています。いずれにせよ、売れたとしてもたかが知れているので、本の宣伝スペースと割り切って、1冊づつ見本誌として用意するのが良かったかなと思います。

交代要員

　当日は、会社の後輩に手伝ってもらって2人でのオペレーションでした。2人だとトイレ休憩するくらいが精一杯で、ゆっくり会場を回る余裕はありませんでした。開催前にヤバそうと気がついたのですが、参加証の追加発行をしていなかったのでスタッフの追加が出来なかったです。次回は、執筆者も増やした上で複数人のオペレーションを目指します。

ファシリティ面

　当日設営してみると、やはりファシリティ面で改善の余地に気が付きました。箇条書きで列挙すると次のとおりです

  • A2ポスターは、裏にダンボールで補強する必要がある
  • それ以前にA2ポスターを机の上に置くと、わりと邪魔
  • テーブル布の全面にポスターを貼ればよかった
  • 見本誌不足。2冊じゃなくて、4〜5冊くらい用意する。あと見本誌と解りやすくする

印刷数

　これは、全然知らなかったのですが、印刷所に500冊注文したとして500冊ちょうどに来るわけではなく、それより多い数を用意されるようです。これは落丁対策なのです。で、ダンボールの中に何冊とか書いた紙があるのですが、これを見ずに捨ててしまいました。感覚的には、520冊くらいあったような気がするのですが、正確なところが解りません。正確な本の冊数が解れば、後で売上との突き合わせとかに活用出来たのですが、後の祭りです。

良かった点

　ネガティブな面だけ挙げるのも何なので、良かった点もあげておきます。

レジアプリの導入

　手伝ってくれた後輩のアイデアで、レジアプリの即売レジというアプリを導入しました。これが中々便利で、時間帯ごとの売上も記録できます。

即売レジ

　今回は彼のiPhoneを専有してしまったので、次回はiPadにこれを入れて使うことにします。

事前告知

　執筆が押している中、できるだけブログやTwitterで告知するように努めてきました。労力の割には上手くいったようで、販売開始後のスタートダッシュにつながったと思います。一方で、もう少しチラ見せ的な要素で、内容に対する周知もできたかなと思うので、これも次回検討です。

本のテーマの選定

　技術書典に出ると決めた時に、時間を掛けて検討したのがどういった本の内容にするかです。同人誌なのだから、少し遊びの要素を入れて普段仕事でしているところから外すことも考えました。でも、初回なので色々手間取ることが予想できていたので、執筆自体で苦労しないテーマを選びました。そうすると必然的にAWSになります。
　では、AWSの中で何を書くか。網羅的な内容は、商業誌で既にやっています。また入門的な内容も、mochikoさんが既に良いものを出していて今更参入余地もありません。それでは、特化型とすることにしました。そうした中で書きたいテーマを幾つか考えました。

  • IAM本
  • Cognito本
  • サーバレス本
  • S3本

　サーバレス本は、テーマが広くもう少し絞り込む必要を感じました。一方で、API GatewayとかLambdaにすると、既に多数の同人誌があるので今回は見送っています。S3本は、個人的には出したいのですが、これで救われる人はどれくらいいるのかなということで一旦見送りです。Cognito本も有力候補なのですが、その前にIAMに比べて必要とする人は少ないです。なので、これも次回でよいかなと見送りました。
　結果的にIAMにして、そこそこ当たったかなと思います。Twitterのタイムラインみていても、反響が良いようです。また特にkmutoさんの「同人誌らしい同人誌」という下記のコメントは嬉しかったです。


感想と次回に向けて

　という訳で、なんとか初参加の技術書典を成功のうちに終えることができました。技術書典という場を提供してくださった運営の方、ボランディアの方、ありがとうございます。あの人数のイベントをまわすのは、並大抵の労力では出来ないと思います。本当に感謝しかありません。

　さて次回ですが、IAM本を書いていて足りないと思った部分を続編として書こうと思います。テーマはAWSのサービスを使ったセキュリティ強化で10章で取り扱ったCloudTrailやConfig,GuardDuty,組織アカウント、場合によってはSecurityHubやControllTowerあたりを駆使しようかと思います。もう一冊は全くAWSと別分野を考えています。子供向けのプログラム本でも書いてみようかなと思案中です。
　あとは、今回単独での参加でしたが、次回は同僚にも書いて貰って複数人で新刊を用意できるように、動いて行こうと思います。それでは、また次回参加するを楽しみにしています。

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

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

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

f:id:dkfj:20190915213218p:plain

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のお２６です
この辺です

f:id:dkfj:20190915100134j:plain

サークルチェック

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

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

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認定 ソリューションアーキテクト-アソシエイト

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

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2019/04/20
  • メディア: 単行本
  • この商品を含むブログを見る

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のマッピングは、アカウントごとに異なっています。あるアカウントの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のサブネットの作成や詳細のところに出てくるので、それをご参照ください。

f:id:dkfj:20190826081052p:plain
f:id:dkfj:20190826081353p:plain

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

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

f:id:dkfj:20190826081812p:plain

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

まとめ

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

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

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


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

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

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2019/04/20
  • メディア: 単行本
  • この商品を含むブログを見る
BOOTHで電子書籍販売中！！
takuros.booth.pm