さわらブログ

さわら(@xhiroga)の技術ブログ

書評 - AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー

booth.pm

アップデートの早い AWS のアカウントセキュリティ界隈において、2020 年時点での最新がキャッチアップできる本でした。

個人的には以前から興味のあったテーマなので知っていることも多かったです。しかし、以下の 2 点を新たに知ることができたのが収穫でした。

  1. Organization と StackSets が連携できる。新たに Organization に加わったアカウントがあれば自動で StackSets の Stack を展開できるようになること。
  2. アカウントセキュリティの各種サービスと Security Hub の連携について。

以下、私の感想と見解。

Organization と StackSets の連携

第 5 章 CloudFormation を利⽤した構成管理で紹介されている AWS の機能です。

筆者の紹介通り、IAM との相性の良いサービスだと思いました。 私の関わっている案件では、同じスタックを複数の環境にデプロイするために CircleCI のワークフローを使っています。しかしながらこの運用、アカウントが増えるたびにワークフローを追加するのが辛かった。 Organization+StackSets をありがたく利用したいと考えています。

ただ、アカウント周りに関しては AWS SSO でも良いのかもしれませんね。 AWS CLIAWS CDK と SSO の相性を調べていないのでなんとも言えないのですが、より楽な方を選びたいものです。

IAM 以外で個人的に検討していたのが、AWS Config の管理です。 AWS Config はちょくちょくルールを追加したくなることが予想されたので、なんらかの方法で自動的に更新したいなと考えていました。 さて本件、ちょっと罠がありました。(2021 年 4 月時点) StackSets に登録している CFn テンプレートを更新するということは、StackSets 自体を CloudFormation のスタックで管理したくなりますよね?(ややこしい) ところが、CloudFormation の StackSets リソースは DELEGATED_ADMIN を使った SERVICE_MANAGED スタックセットの作成をサポートしていません。

ここで新しい概念、DELEGATED_ADMIN について。StackSets を複数アカウントに適用するには、Organization の親アカウントに登録する方法と、親アカウントが認めたアカウントに登録する方法があります。 後者が DELEGATED_ADMIN ですね。AWS が推奨する方法も後者です。 これは納得できて、Organization の親アカウントなんか SRE が普段使いするのに相応しくありません。

ところが CloudFormation は DELEGATED_ADMIN として SERVICE_MANAGED(Organization と連携している、という意味)の StackSets の作成に対応していないとのこと。 やるなら API 叩くことになるんですね。うーん。。。今後に期待です。

アカウントセキュリティの各種サービスと Security Hub の連携について

第 7 章 障害の検知と復旧の考え⽅で紹介されています。

この章の具体的な内容が役立ったというより、アカウントセキュリティの通知の複雑さについて共感できたのが嬉しかったです。

とはいえ、まずは Security Hub と GuardDuty, AWS Config の繋ぎこみをした方が良いという筆者の見解に同意です。 それで通知の具合が良くない時に個別の設定をすれば良いかなと。

まあ一番嬉しいのは Control Tower が AWS Config に加えて Guarduty, Security Hub の設定を全部やってくれることなんですけどね。

Control Tower と GuardDuty の連携については公式ブログがあったのでご参考まで。

Enabling Amazon GuardDuty in AWS Control Tower using Delegated Administrator

まとめ

知るべきことが多い上にアップデートが早いアカウントセキュリティについて日本語でまとめられた貴重な本でした。 サクッと読んで知らない知識を補完するだけでも価値はあると思うので、気になる方は読まれると良いのではないでしょうか。