AWS認定セキュリティ – 専門知識の試験対策本を書きました

　Twitter等で告知しておりましたが、AWS認定セキュリティ 専門知識の試験対策本を書きました。販売開始は今月末の、2020年7月29日です。

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

書名や価格は暫定版だと思います。
書名・価格が正式なものになっています。

試験対策本の内容

　試験対策本なので、試験要項に沿った形の章立てとなっております。最初の1章で、AWS認定試験の概要と試験勉強の仕方、教材についての説明をしています。2〜6章がメインで出題分野ごとに、対応するサービスとその考え方をまとめています。そして7章でWell-Architectedについては、セキュリティの柱を取り上げています。ここでは、実際にWell-Architectedをダウンロードして読んでもらうという前提を置いたうえで、では対策として実際にどのようなサービスを使うのかを補完する形でまとめています。最後はお約束の問題の解き方と、練習問題です。

1. AWS認定試験の概要
2. IDおよびアクセス管理
3. インフラストラクチャのセキュリティ
4. データ保護
5. ログと監視
6. インシデント対応
7. Well-Architected
8. 問題の解き方

著者について

　今回も会社の同僚と書いています。上野さんは、2020年のAWSのAPN AmbassadorおよびTop EngineersかつALL AWS Certifications Engineerという長い肩書を持ってます。要は、AWSの認定試験12種全部持ってアンバサダーにも選ばれているという実力者です。最近、精力的にJAWSUG等に登壇しているのですが、どんなテーマで話してもどうやって試験に受かるのという質問が一番多くて困っているそうです。AWSの認定試験を受けだして、2年かそこらくらいで全部取ってしまっているのが脱帽です。あと、情報処理試験の高度も、ほとんど持っています。
　もう一人の共著者の小林さんは、情報処理試験の高度をコンプリートしているという世にも珍しい人です。なんだか知らないけど、半年ごとに資格を取っていってあっという間にコンプリートしていました。諸般の事情でAWSの試験はあまり受けていないですが、セキュリティの対策本を書くから取っておいてというと、あっさり試験に合格していました。もちろん、プロも取っています。たぶん、AWS認定の受験を再開したら、あっという間に全部取ってしまうのではと思っています。
　また、過去に一緒に書いたイラスト図解式 この一冊で全部わかるWeb技術の基本のメイン著者でもあります。この本の6割以上は、小林さんが書いていたと思います。私は、2ページほどしか書いていません。この本が発売して３年経ちますが未だに売れ続けていて、今でもカテゴリートップに輝いていることが多々あります。先日もまた増刷して、合計９刷、累計25,000部になっています。技術書の中では、大ベストセラーです。

イラスト図解式 この一冊で全部わかるWeb技術の基本

　ということで、AWSについても試験についてもプロフェッショナルな2人が中心に書き上げています。私は、AWS認定も資格試験もコンプリートしていまあせんが、IAM本とアカウントセキュリティ本を書いていたということで、１＆２章の担当しています。

booth.pm
booth.pm

本書のお勧めポイント

　本書のお勧めポイントとしては、試験対策本として書かれていますがAWSのセキュリティサービスの指南書にもなっているという点です。具体的な設定方法などは範疇外なので書いていませんが、どういう時にどのようなサービスを使えば良いのか、またその理由は何なのかを解るように書いています。この辺り、上野さんが最近JAWSUGに幾つか登壇し話しているような内容です。スライド等を見ていただければ、イメージつくのではないでしょうか？

speakerdeck.com

　後はやっぱり練習問題ですね。私は問題を作るという能力にかけているようですが、二人が作る問題は的確でこんな感じで出てきそうというのが取り揃えられています。最後の２択で迷うような引っ掛け問題も用意されていて芸が細かいなぁと思います。当然、解説の方もしっかり説明していて、どうしてその答えが導出されるのか順を追って解説しています。

感想

　日本初のAWS認定試験のスペシャリティの対策本です。期待しておいてください。日本のセキュリティー専門知識の受験者数と合格者数を大幅に増やして、AWS本国の試験担当の人に、日本はなんでセキュリティのスペシャリティだけ突出して高いのだろうと言わせたいです。みんなで認定セキュリティを合格しましょう！！
　あと執筆していて気がついたのですが、プロの対策本を書くよりスペシャリティの方がテーマがハッキリしていて書きやすいなと思いました。売れ行き好調であれば、別のスペシャリティの対策本を書いても良いかなと思い出しています。あとは、プロ本もいよいよ出てきたので、そのうち私もプロ対策本を書くことに挑戦してみようかとも思います。まぁ時間が限られているので、今の宿題を全部片付けてからですが。。。あと個人的には、やっぱりAWS認定を全部取っておかないとという思いを強くしました。あと３つなので、月１個くらいは取れるように精進します。
　現在、最終校正中で目次がまだ確定していません。確定次第、また順次紹介していきます。Amazonは最近書籍の在庫補充が遅いので、一度品切れになると中々買えません。確実に買いたい場合は今のうちに予約しておいてください。それでは、お楽しみに〜

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

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

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

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

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

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

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

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

　自動生成された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さんが興味をしてしてくれました。私の方も、今年は家族旅行とセットで色々な地方の勉強会に生きたいと思っていたところだったので、ちょうどお互いの思惑がマッチしたということです。
※新型コロナがこんな状況になるとは思っていなかったです。

わいもIAMでわいわいしたーい。
ちな、富山 https://t.co/0UGw5iD2Eh

— miamo (@miamo_infra) 2020年1月11日

感想

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

booth.pm

booth.pm

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

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

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

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

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

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

組織を作る

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

まとめ

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

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

booth.pm

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

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

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

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

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

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

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

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

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

DevLove Kansai AWS from Takuro Sasaki

www.slideshare.net

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

まとめ

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

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

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

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

執筆時間

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

業務システム設計・移行ガイド：　５００時間
アカウントセキュリティ本：　　　６０時間

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

印税率

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

　3,000（冊）× 3,500（円） × 0.08　＝　84万円

　対する同人誌です。ここはBOOTHという破壊的なプラットフォームがあるので、このBOOTHで印刷原価が掛からない電子書籍を前提とします。BOOTHの何が破壊的かというと、印税率ではなく単に販売手数料を取るというモデルなのです。そして、その手数料がたったの3%程度。つまり97%と殆どが著者の取り分となります。売上の計算に、書籍代を1,000円で100部売れたと仮定します。この100部は、技術書典７の平均頒布数が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からダウンロードできる無料サンプルをみてください

CloudFormation StackSetsとは？

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

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

AWS Organizations × CloudFormation StackSetsの素晴らしさ

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

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のアカウントセキュリティ本を書きました #技術書典