プログラマでありたい

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

AWS Control Towerの削除

 AWS Control Towerは、複数のAWSアカウントを管理するためのサービスです。AWS Organizationsを構築して、傘下のアカウントのセキュリティとガバナンスを、Security HubとSCPを利用しながらガッチリと守り、各アカウントへのログインにAWS SSOを用意したりと至れり尽くせりなサービスです。
 複数のAWSアカウントを監理している方は、非常に興味を持っているのではないでしょうか?今日は、そんなControl Towerの消し方を御紹介します。

Control Towerと関連AWSアカウントの消し方の手順

 とりあえずControl Towerを評価してみたくて、Control Towerを作ってみたものの消し方が難解すぎて四苦八苦する人を散見するようになりました。そんな人のために、主に自分のために記録を残しておきます。Control Towerとそれによって作られたAWSアカウントの消し方は、次のような流れとなります。

  1. Control Tower の環境クリーンアップを実施する
  2. メンバーアカウントの登録解除
  3. 各アカウントの解約

Control Tower の環境クリーンアップを実施する

 さらっと書いていますが、このControl Towerの環境クリーンアップ(消し方)が大変です。公式ドキュメントにわざわざ消し方が用意されています。

廃止プロセスの概要
Landing Zoneの廃止
廃止処理中に削除されないリソース

 まずControl Towerのランディングゾーンを消すためには、AWSサポートに依頼をする必要があります。サポートレベルは無料のベーシックでも大丈夫ですので、「アカウントと費用に関する問い合わせ」からControl Towerの削除依頼を出します。そうすると、担当のチームに引き継がれ1週間以内くらいで準備がされます。これがControl Tower削除の際の1つ目のつまづきです。

 そうすると、Control Towerの設定ページでランディングゾーンの廃止のボタンが出てきます。おどろおどろしい警告を読んで、チェックすると削除プロセスが開始します。これが結構時間がかかり、数時間は見ておきましょう。

f:id:dkfj:20200629090518p:plain
f:id:dkfj:20200529095312p:plain
f:id:dkfj:20200529095338p:plain
f:id:dkfj:20200529095355p:plain
f:id:dkfj:20200529095416p:plain


 この削除プロセスが終わっても、Control Towerが作った生成物が全て削除される訳ではありません。具体的には、OrganizationsとAWS SSOとS3バケット、傘下のメンバーアカウント(AWSアカウント)が残ります。これらを手動で削除していく必要があります。
docs.aws.amazon.com

 Control Towerだけを消したい場合は、ここまでの作業で大丈夫です。

メンバーアカウントの削除

 Control Towerは、Organizationsを作成時にAuditとLog archiveという名前のAWSアカウントを作成します。

f:id:dkfj:20200629022450p:plain

 これらを削除するのですが、AWSアカウントの削除はルートアカウントでしか行なえません。そして、ルートアカウントのメールアドレスは指定したもののパスワードが解りません。これが2つ目のつまづきがあります。実は、Control Towerからアカウント作成時に、自動的に長い桁数のパスワードが設定され、どこに表示されるでもなく破棄されています。なので、正解はパスワード忘れで、パスワードを再発行することです。

f:id:dkfj:20200629023139p:plain

 別にパスワード忘れていないのにとイラッとしますが細かい事は水に流しましょう。パスワードの設定の際に、どうせすぐ消すからと簡単なパスワードを設定しようとすると、1文字以上の数字・大文字・記号を求められて更にイラッとします。
 無事ログインができると、後はマイアカウントからアカウントのアカウント設定から解約するだけです。AuditとLog archiveのアカウントを解約すると、次のような状態になります。

f:id:dkfj:20200629025243p:plain

 自動生成されたAWSアカウント以外に、他に新規でアカウントを作っている場合はそれも削除しましょう。Organizationsに紐づくアカウントが全てなくなっている。或いは停止状態すると、Control Towerで作ったアカウントも削除できるようになります。マスターアカウントであるControl Towerを作ったアカウントに、ルートアカウントでログインして削除しましょう。

まとめ

 Control Towerを廃止しない状態でも、メンバーアカウントを削除することは可能だと思います。今回は、AWSの公式の手順に従って削除してみました。またControl Towerだけ削除したいケースもあると思いますので、その際は、『Control Tower の環境クリーンアップを実施する』のみを実行してください。
 そもそもControl Towerとはなんぞやと気になっている人がいるとは思うので、おいおい解説します。また、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』という本にも概要を説明していますので、興味があれば是非読んでみてください。

booth.pm

富山IT勉強会で論理登壇してきました

先日開催された富山IT勉強会で、リモートで登壇しました。参加者も全員リモートなので、完全なオンライン勉強会でした。

toyama-it.connpass.com

発表内容と当日の進め方

 当日はIAMの輪読会ということで、最初に私の方からIAM本ならびにAWSアカウントのセキュリティを守るにはという内容で30分くらい話したあとで、今回の会の主催者の@miamo_infraさんから、前半の解説。続いて、後半の気になるところをディスカッションしながら読むというスタイルでした。並行してSlackでコメントや疑問点をつぶやきながら、随時拾っていくということもやっていました。少人数だったので、わりと濃密に出来たのではないかと思っています。
 当日の発表資料はこちらです。

speakerdeck.com

参加の経緯

 富山の勉強会に参加した経緯としては、Twitterからです。東京でIAMの輪読会が開催され、それに@miamo_infraさんが興味をしてしてくれました。私の方も、今年は家族旅行とセットで色々な地方の勉強会に生きたいと思っていたところだったので、ちょうどお互いの思惑がマッチしたということです。
※新型コロナがこんな状況になるとは思っていなかったです。

感想

 初のオンライン登壇でしたが、距離の壁を取っ払えるのは良いなと思いました。うまく活用したら、全国どこでも登壇できるので、これからはオンラインの勉強会にも積極的に参加していきたいと思います。都合が付けばどこでも参加するので、登壇依頼とかお気軽にしてください。また新型コロナが収まったら、物理参加もしたいと思います。目標としては、月1で地方の勉強会に参加したいです。もちろん交通費は自腹なので、その辺りの心配も不要です。

booth.pm

booth.pm

チームの力を自分の力とする

昨日、『技術者であることを諦めない』というタイトルでポエムを書きました。ポエムの内容は、IT業界、特にSIerにいると段々と技術に特化して開発者ですというだけでいるのも難しくなりますよと。でも、自分の技術をアップデートしていくことも重要だよね。時間がなくて大変だよねと、世の中の中年世代の気持ちを代弁する形を装いつつ、自分の感想を述べさせてもらいました。長くなったので分割して、今日は具体的なハウツー的なことを書いています。

チームの力を自分の力とする

 チームのリーダーやマネージャーになって、技術のアップデートをしていくことが厳しくなった場合の私なりのハウツーです。自分の技術力向上のために割く時間が無くなった時に有効な手段が、チームメンバーなど周りの人の力を自分の力としてしまうことです。特定の分野についての知見が必要になれば、それが周りに詳しい人がいれば概要を頭に入れた上で、その人に解らなかった部分や詳しく聞きたい部分を聞けばよいのです。また詳しい人がいないのであれば、メンバーに調査や試行してもらいその結果を教えてもらうのです。その成果を持った上で、その知見を使って打ち合わせなり実際のプロジェクトの遂行なりをしていきます。詳しい人に教えて貰っただけでは、知識のトランスファーとしては5割程度だと思いますが、それを使って自分でやることにより7〜8割の状態に短時間で持っていけます。それでも足りなければ、教えて貰った人を第一人者として連れてきてやってもらえばよいのです。
 このような方法だと、リーダー/マネージャーも短い時間で技術のキャッチアップができます。また技術を提供したメンバーも、人に知識をトランスファーすることにより、より理解が深まります。またチームとして対応できることの多様性が上がり、組織全体としてのケイパビリティが向上します。この話はチームに対して影響力を行使できるという前提での話になってますが、別にそうでなくてもチームメンバー同士でもカジュアルにできる内容かなとも思います。

チームの方向性をリードする

 先程のメソッドは、チームメンバーのリソース(時間)を使うことになります。そのため、全く検討外れの方向にリソースを張ると、そのメンバーに対しても損失だし、チーム全体としても損失になります。つまり、技術動向や今後の事業の方向性を見定めて、どちらの方向に向かっていくのかリードすることになります。これこそが、リーダーやマネージャーの重要な仕事に一つだと考えています。
 注意点としては、方向性を考える上でも、ちゃんとメンバーあるいは外の人間の意見を聞いて自分がずれていないか、絶えずチェックしつづける必要があります。現場から離れれば離れるほど、技術の動向に対する感性は鈍ります。変なプライドを持たず、現場の意見を聞きましょう。一方で、技術の流行り廃りというのに影響されすぎないように注意する必要もあります。例えば、Kubernetesが流行っていると、技術者としては使ってみたくなります。一度検証してみることは大事ですが、自分が向かっている事業・プロジェクトに対して、その技術が本当に合っているのか、そういったことを見極める必要もあります。自分の組織にとって、Too Muchだと思ったら、その論拠を元に現場と対話をしましょう。何も言わずに却下すると恨まれます。

組織を作る

 こういった活動をしていくのは、結局は組織を作っていくことと同じなのだと思います。技術を主題に扱っていましたが、事業に必要なのが業務知識であったり、プロジェクト管理能力だったら、そちらの方を育てていく事になります。リーダーやマネージャーとして重要なのは、自分がメンバーの中で一番優秀であることではなく、メンバーのそれぞれに自分より優秀な分野をどんどん作らせていくことだと思います。最初の方は、どうしても自分がやったほうが早いと思うこともありますが、そこはぐっと我慢です。なぜ、世界は貿易をした方が良いのかの下敷きとなっている比較優位の考え方と同じです。

まとめ

 まぁ、何でこんな話を書いたかの一つは、私は会社の中でAWSが一番詳しい人と認識されている節があるのですが、実際のところは個々の要素の詳細に対しては殆どキャッチアップできていません。だいたい何ができるか把握しておいて、実際に必要になったら(外部の人間を含め)一番詳しい人にお願いしているだけです。そういったやり方もあるんだよというのを言語化してみました。
 一方で、たまに特定分野についてガッツリと知識を得たい場合があります。その時は、IAM本アカウントセキュリティ本のように、自分でまとまった時間を投下してキャッチアップするようにしています。ということで、最後はステマで締めましたが、いかがでしたでしょうか?

See Also:
技術者であることを諦めない

booth.pm

技術者であることを諦めない

 だいぶ前にAWSのAmbassadorが集まっての懇親会がありました。年齢の話になって聞いていると、どうやら私が最年長グループでした。最年長!!おっさんです。私は42歳で、役割的な部分を考えれば、そうなるのも無理はないのかなという気がします。せっかくなので、ポエムっぽいブログエントリーを残しておきます。

SIerの中での技術者の生き方

 技術者と書くのがよいのか、ITエンジニアと書くのがよいのかイマイチ解りませんが、ここでの技術者は、下記のように定義しておきます
※あくまでこの文脈の中だけの定義です。

  • 主たる業務に対して、自身のもつITの技能・知識を持って業務を遂行している
  • 業務で必要とされる技術の変化に追随しつづけている

 ここで重要なのが2つ目の技術の変化に対して追随し続けるという点です。一口にSIerといっても対象とする業種や業態によって必要とする技術は大きく違います。業務知識がとにかく重要でそれを実装する技術については十年一昔はなんのその、COBOLで作られた数十年もののシステムが今日も元気に動き続けるところもあれば、クラウド業界のように日々新しいサービスがでてくるといった業界もあります。大切なのは、まずは仕事を遂行する上での技術力を得ることだと思います。一方で、今の仕事がどれくらい続くのか、今働いている会社がなくなったとして、同様の給料を維持できるのかも考える必要があるのが辛いところです。

 また経験を重ねて昇進していくと、通常であれば給与がアップしていきます。会社視点で考えると、その分に見合ったアウトプットを期待されることなります。1日の時間は限られているので、アウトプットを増やすには単位時間あたりの生産性を高めるしかありません。例えば若手の時のアウトプットが設計やコーディングなど直接的なコードがアウトプットが中心だとして、給料が2倍・3倍となった時に生産性も2倍・3倍に出来るかという問題に直面します。一部では2倍・3倍の生産性を実現する人もいますが、大半の人は標準レベルの人に対して数倍の生産性は発揮できません。そのため、他の付加価値をあげる方法にシフトしていく事になります。
 その一つが技術者が嫌がるマネジメントですね。個人としては数倍の生産性を出せなくても、チームとして活動し個人の数倍のアウトプットを出すことは可能です。そのチームを率いるリーダーは、それだけ分の付加価値を出しているのと等しくなります。ということで、一定の年次にいくとマネジメントが主要業務になることが多くなります。
 一方で、マネジメントスキルだけを伸ばしていけば、それで大丈夫かというとそうでもないのが難しいところです。10年に一度ほど、或いはもっと短い期間で断続的にゲームチェンジを強いられる革新が発生しつづけています。そういった局面で、従来のやり方で良いのかという問題が発生します。大きな会社であれば、その辺りの手法を標準化してマネジメントレベルまで落とし込むのかもしれないですが、多くの会社はマネジメント層自体が自身で対応を考えていく必要があります。そうなると、やっぱりIT業界にいる限り、マネジメント層にも技術には無縁ではいられなくなります。

時間が無い中での技術との関わり方

 じゃぁ、常に技術力をアップデートし続けないといけないとして、どうやってそれを身につけるのか。日々の業務や研修などを通じる方法と、自己研鑽の2種類があると思います。前者は所属する組織によって状況は大きく異ると思うので、後者の自己研鑽にフォーカスしようと思います。自己研鑽するにしても、時間が限られています。自由に使える時間は個人差がありますが、30〜50代くらいでは結婚や子育てなどの時期とかぶることが多いでしょう。そうなると、その貴重な時間をどこに振るかが重要になります。
 個人的なおすすめとしては、今持っている自分の専門の隣接領域が良いと思っています。単一の専門性だと100メートル走の世界と同じで、その先にもっともっと凄い人がいます。なので、勝手に複数の領域を組み合わせて、ベクトルとして合成できるようにするのです。このあたり、だいぶ昔のスライドですが、説明しているので見てみてください。

www.slideshare.net

 大切なのは、積み重ねになる領域を選ぶことです。自分より数倍頭の回転が早い新人は現れる可能性はありますが、インフラ経験10年とかアプリ開発歴20年の新人は(たぶん)現れません。経験の積み重ねを活かせる方向に技術をアップデートしていきましょう。

まとめ

 長くなったので、もう1回くらいに分割して書きます。とにかくおっさんになっても、マネージャーになっても技術者であることは諦めないでねという思いです。たとえ、スーパーカーみたいな若者が一杯台頭してきても、経験を活かして生き残る戦略を考えながら頑張りましょう。続きは、また次回。

2020年4月3日追記:
続き書きました
blog.takuros.net

技術本の著者からみた商業誌と同人誌の違い

 先日リリースした『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』は同人誌として2冊目になります。また今回は、サークル主として他のメンバー3冊の企画作りを少し手伝わせて貰いました。なので、何となく同人誌の世界も解ってきたと言っても良いような気がするので、すこしエラそうかもしれませんが、技術本の著者から見た商業誌と同人誌の違いを述べさせて貰います。

f:id:dkfj:20200323084651j:plain

執筆時間

 まず商業誌である『Amazon Web Services 業務システム設計・移行ガイド』は、384ページです。これに対して『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』は104ページです。ページ数にすると。3.7倍の違いがあります。が、実は文字数ベースでいうと、もう少し大きな開きがあります。27万字と6万字で、4.5倍と差が開きます。
 これは、同人誌フォーマットが紙のサイズもA5と小さく、文字が大きめというのが一般的だからです。もちろん商業誌でもジャンルによっては、同じような傾向のものもありますが、一般的には1ページあたりのボリュームは商業誌の方が多いです。
 そしてここからは執筆の累計時間から1ページの生産性を求めてみましょう。厳密に測っていないし、商業誌の方は分担して書いたという違いはありますが、自分ひとりで書いたと仮定するとだいたいこんな感じだったと思います。

業務システム設計・移行ガイド: 500時間
アカウントセキュリティ本:   60時間

 執筆時間は個人差が多く、私は割と執筆が早いほうです。人によっては、2倍3倍の時間が掛かることもあると思います。また、純粋に原稿に向かい合ってる時間なので、それ以外の構想とか検討、執筆後の校正の時間とかも入れていません。

印税率

 そして、ここからが下世話ながらみんな気になる印税の話です。商業誌の印税率は、会社や本のジャンルごとによって違います。パターンとして多いのが8%なので、そこで計算することにします。著者に入ってくる印税は、刷り数×書籍価格×印税率になります。初版の刷り数は、これもケースバイケースですが、3,000部とします。(最近は、これより少ないケースの方が多いようですが。)そうすると、書籍代を3,500円とした場合に著者に入ってくる印税は次のようになります。

 3,000(冊)× 3,500(円) × 0.08 = 84万円

 対する同人誌です。ここはBOOTHという破壊的なプラットフォームがあるので、このBOOTHで印刷原価が掛からない電子書籍を前提とします。BOOTHの何が破壊的かというと、印税率ではなく単に販売手数料を取るというモデルなのです。そして、その手数料がたったの3%程度。つまり97%と殆どが著者の取り分となります。売上の計算に、書籍代を1,000円で100部売れたと仮定します。この100部は、技術書典7の平均頒布数が133冊から導出しました。技術書典というお祭りという特殊要因を抜いても、テーマ選定とマーケティングをしっかりすると、100部という数字は非現実な数字ではないです。

 100(冊) × 1,000(円) × 0.97 = 9万7千円

この数字に執筆時間で割って、時間給を出してみましょう。

商業誌:840,000 ÷ 500 = 1,680円
同人誌: 97,000 ÷ 60 = 1,616円

 ほとんど同じになりますね。そして、あまり割が良いものでもありません。では、それぞれヒットしたらどうなるでしょう?技術書の商業誌だと1万部売れたらまずまず大人気といえます。また同人誌だと500冊かなと思います。それぞれ売上を出した上で、時給を出してみましょう。

商業誌:280万円 ÷ 500 = 5,600円
同人誌:48万5千円 ÷ 60 = 8,083円

 ここまでくると、時間辺りの単価としてはそれなりになります。が、エンジニアとして普通に働いているのと、それほど変わらないような気もします。で、私の場合はどうだったかというと、商業誌だと1万冊とか2万冊売れているのが幾つかありますし、同人誌の場合は前作が1,500円で1,500冊以上売れています。商業誌で1万部売るのと同人誌で500部売るのだったら、同人誌の方がハードル低いかなと思います。簡単単純な利益を追求するのであれば、私の場合は同人誌の方が今は実入りが良いというのが現状です。

企画

 刷り数を踏まえた上で、じゃあ同人誌と商業誌は企画段階で何が違うのかという点です。これははっきりしていて、商業誌は出版社も利益を出さないといけないので、最低3,000部売れる、そして1万冊くらいは狙えるテーマを選ぶ必要があります。そうすると、世の中のニーズ的には10万人以上の潜在的な市場がある世界です。10万人となると、それなりにビックなテーマで、必然的に競合が多くなります。これに対して、同人誌は100冊売れれば充分なので、ニッチなテーマを選べます。この違いは大きいです。
 大きな市場という意味だと、必然的には初級・入門的な内容になります。何故ならば、初級者より中級者・上級者が多い市場というのは、一般的には存在しないからです。逆に、同人誌は100部で良いので市場の大きさより競合の少なさの方が重要になります。そうすると、テーマの多様性が増え、中級・上級向けの本も多数でてきています。

この辺り、5年前くらいに考えていたようで、物理本の制約がなくなればと思っておりました。現実は、そっちに向かっているのかもしれませんね。
blog.takuros.net

編集者

 じゃぁ単純に同人誌(個人出版)が今後増えてくるのかというと、そうでもないでしょう。商業出版では基本的に編集者が付きます。この編集者の役割というのは、やはり大きいと思います。著者という存在は、そのテーマにおいてはそれなりの知識を有しているものです。その著者が、そのまま文章を書くと同程度の知識を持つ人間ではないと、50%も伝わらないことが多いです。そこを助けてくれるのが編集者です。
 私は10冊以上の商業誌の執筆経験がありますが、編集が入った自分の文章を読むと、やはり伝わりやすさが違います。また色々指摘された経験があるので、ある程度は編集者の視点で文章を校正することもできるようになってきました。でも、やっぱり編集者はいて欲しい。同人誌向けにエージェント的な編集者がいても良いのではと思っています。ちなみに、米国だとエージェントとしての編集者が主流で、書籍の企画から出版社への交渉まで著者側についてするスタイルが多いようです。日本も、こういったモデルが出てくるかなと予想しています。

まとめ

 いろいろツラツラと書き連ねましたが、同人誌と商業誌のどちらが良いかという話ではありません。単に違いがこうだよと整理してみただけです。執筆に興味がある人は、同人誌というのも選択肢に入れても良いのじゃないかなと思います。私は、どちらの良さも知っているので、お声がかかる限りは商業誌でも書き続けますし、同人誌もしばらくは続けます。同じ執筆でも、プラットフォームを変えることで、見えてくるものが違うなということに気がついた次第です。今年はもっと色々なプラットフォームに挑戦するつもりです。

booth.pm

See Also
AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしい
AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策
AWSのアカウントセキュリティ本を書きました #技術書典

AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしい

 昨日のブログエントリーで、AWS Organizations × CloudFormation StackSetsが素晴らしいという話をして、少しだけ紹介しました。今日も、もう少しだけ詳しく説明します。まずは、CloudFormation StackSetsから
※本エントリーの内容は、『AWSの薄い本 アカウントセキュリティのベーシック』で手順を含めて解説しています。興味がある方はBOOTHからダウンロードできる無料サンプルをみてください

f:id:dkfj:20200323084651j:plain

CloudFormation StackSetsとは?

 CloudFormation StackSets(CFn StackSets)は、CloudFormationのテンプレートを元に、任意のAWSアカウント・リージョンに対してスタックの作成・実行ができる機能です。ベーシックなCloudFormationは、アカウントにログインしてリージョンを選んで一つずつ実行する必要があります。同じ設定を複数のアカウントに流し込もうとすると、CLI等を駆使してもそれなりに面倒くさいのも事実です。CFn StackSetsを使うと、その辺りをサクッと管理できるようになります。もちろん、対象アカウントに対して、IAM Role等の準備が必要にはなります。

f:id:dkfj:20200325091547p:plain

図では、Organizationsのマスターアカウント(親アカウント)から実行していますが、権限設定をすればどのアカウントからでも実行可能です。

AWS Organizations × CloudFormation StackSetsの素晴らしさ

 単体でも魅力的なCFn StackSetsですが、Organizationsとの連携機能を使うと、その真価を発揮します。
なんとOrganizationsからアカウントの作成・削除時や、OUの移動時にStackSetsを自動で実行させることができるようになりました。
 つまりアカウント作成時に共通の初期設定をしたり、本番環境用のOUに参加した時により厳しいセキュリティの制約をつけたりするといったような事が、自動でできるようになったのです。アカウントセキュリティ本で繰り返し説明していますが、セキュリティ設定というのはどこか1箇所抜け漏れがあると、そこから侵入される可能性がでてきます。そして人間は(特に私は)、繰り返しの作業を正確にするには向いていません。そういった部分を補完する素晴らしい機能だと思います。

f:id:dkfj:20200324063218p:plain

CloudFormation StackSetsの初期テンプレート

 CFn StackSetsには、サンプルテンプレートが用意されています。そのリストをみてみましょう。

- CloudTrailの有効化
- Configの有効化
- GuardDutyの有効化
- 設定ルール root-account-mfa-enabledの追加
- 設定ルール cloudtrail-enabledの追加
- 設定ルール eip-attachedの追加
- 設定ルール encrypted-volumesの追加

 サンプルといえども結構実用的なものですよね。そして、CFn StackSetsの方向性が見えるものになっています。テンプレートの実体はCloudFormationなので、もちろん自作することが可能です。
 個人的な考えとしては、CloudTrailやConfigなど設定をするテンプレートを作って、それをアカウントID等を引数にわたして一括で設定するチェーンのテンプレートなど、そういった単位でまとめて使えばよいかなと考えています。それを初期設定・ルール設定など幾つかのまとまりで管理すると便利でしょう。

まとめ

AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしいというタイトルそのままのブログエントリーでした。私の興奮が伝わりましたでしょうか?AWSのアカウントセキュリティ本では、100ページに渡って、なぜセキュリティはサービスを使って守らないといけないのか、そしてどのサービスを使えばよいのかを解説しています。興味をもったら是非BOOTHで見てみてください。サンプル版の無料ダウンロードができます。

takuros.booth.pm

AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策
AWSのアカウントセキュリティ本を書きました #技術書典

AWSのアカウントセキュリティ本を書いて気がついた、これからのセキュリティ対策

 昨日の完成したぞエントリーに続き、『AWSの薄い本 アカウントセキュリティのベーシック』関連のエントリーです。
f:id:dkfj:20200323084651j:plain

 私は今まで、あまりセキュリティって好きな分野では無かったです。もちろん必要性は解っていて、その対策等をいろいろ考えてはいたのですが、どこか自分の仕事じゃないなぁと思っていた部分があります。今回、AWSのアカウントセキュリティ本を書いて、ようやく腑に落ちました。それをまとめたのが、次のツィートです。

24時間365日での自動攻撃。では、防御は?

 攻撃者が24時間365日、自動で攻撃してくる中で、それに対して防御する方が手動で対応するのはナンセンスということに気が付きました。もちろん、セキュリティの設計を考えたり、どういった判断をするかという部分で人間が果たすべき役割は大きいです。一方で、そのためのセキュリティの設定や、日々の攻撃に対する防御は人間に向いている仕事なのか?
 多分あまり向いていないのだと思います。セキュリティはどこか一箇所に不備があれば、そこを狙って侵入口をあけて、そこから内部に侵入される類のものです。人間が手動で設定していると、どこかでミスする可能性は高いです。EC2が登場したことにより、同じ設定をコピーして使うことが簡単に出来るようになりました。それ以来、一つ一つのインスタンスを設定して使う人は殆どいなくなり、職人が手を込めて作られて一台一台微妙に設定が異なる人間の温かみがあるサーバーはだいぶ減ったと思います。でもAWSのアカウントの設定という面ではどうか?一つ一つのアカウントごとに、まだまだ手動で設定されているのではないでしょうか?
 今回AWSのアカウントセキュリティ本を書きながら、AWSのサービスの最新の情報を学びました。もともとAWSでは、設定の大部分がCloudFormationなりCLIなりでコードから設定できます。そのうえで、そのコードをアカウントレベルでまとめて適用させる方法が整っています。つまりAWSではアカウント設定というレベルで、インスタンスと同じように同一の設定を簡単にできるようになっています。その手法について、ちょっと紹介してみます。

AWS Organizations × CloudFormation StackSetsの破壊力

 CloudFormationは、テンプレートを元にスタックを作成し、AWSを設定する機能です。その機能の拡張であるCloudFormation StackSetsは、複数のAWSアカウントやリージョンに対しスタックを作成し、一括で設定します。これだけでも充分便利な機能ですが、2020年2月にAWS Organizationsとの連携機能が発表され、ものすごい進化を遂げました。
 Organizations傘下で、アカウント作成・削除時、あるいは特定のOUに参加したタイミングで、自動でCloudFormation StackSetsを実行する機能です。

f:id:dkfj:20200324063218p:plain

 これがあれば、AWSのアカウント設定の自動化がものすごいレベルで進みます。具体的な使い方については、次回紹介しようと思います。
※本にも書いているので、気になる人はBOOTHへGo!!

まとめ

 セキュリティの施策で、設定レベルの作業は人類には向いていないので、テンプレート等を利用して自動化するべきです。AWSでは、そのためのサービスが凄い勢いで整備されてきています。特にAWS Organizations × CloudFormation StackSetsの組み合わせは破壊的です。この存在の有効性を確認できただけで、AWSのアカウントセキュリティ本を書いた意味があったなと実感するほどです。今、思っている事は以上です。

booth.pm

See Also:
AWS Organizations × CloudFormation StackSetsの組み合わせが素晴らしい
AWSのアカウントセキュリティ本を書きました #技術書典