Observeのステップ1：制限時間の設定・観察・データ収集
山原崇史氏：まず1つ目のObserveのステップ、観察です。ここではタイムボックス、制限時間を定めて、観察、データ収集を実施しました。具体的には記載の3点を実施しました。順に説明いたします。
最初にやったのが有識者へのヒアリングです。既存のAWSの構成に最も詳しいエンジニアにヒアリングをしました。今回（の場合）はCTOです。当初、自分には本番環境とステージング環境のアカウントのIAMユーザーが与えられましたが、ヒアリングをしてみたところ、マネジメントアカウントがあることがわかりました。
また、マネジメントアカウントのIAMユーザーでログインをしてOrganizationsの画面を見ると、サンドボックス環境のアカウントも存在することが確認でき、計4つのアカウントがあることがわかりました。
最初に与えられたIAMユーザーだけでいろいろと調査を進めていたら、残り2アカウントの存在に気づかなかったかもしれないので、こういうヒアリングも大事かなと思います。
ここでTipsとしてヒアリングのコツです。あなたがチームでAWSの一般的な知識に最も詳しくて、他のメンバーとの知識にギャップがあるような場合、AWSの正しい用語だけを使って会話していると、逆に伝わらないことがあるかもしれないので、別の表現も試してみましょうというお話です。
最初にあるのは失敗例です。自分から「Organizationsのマネジメントアカウントに入れるIAMユーザーをください」と言っても、用語的には正しいとは思いますが、「マネジメントアカウントってなんじゃ」みたいな感じで、相手もわからなくなってしまうかもしれません。
それに対して成功例です。「各AWSアカウントの親アカウントみたいなやつ、ありますよね」「全アカウントの請求情報が見られたりするやつです」「そのアカウントに入れるIAMユーザーをください」と。
こういったかたちでちょっとかみ砕いて話をすると伝わることもあるので、知識にギャップがあるような場合は、コミュニケーションの方法について工夫をするといいかもしれません。
Observeのステップ2：既存AWSリソースの確認
Observeはまだ続きます。2番目が既存AWSリソースの確認です。前提として、弊社では多くのAWSリソースをコード化済みです。IaCのツールとしては、Terraformを利用しています。
ただ、一部のAWSリソースはあえてコード化せずに、代わりに作成時の手順と設定意図をドキュメントに残す方針としていました。例えば、AWS公式のハンズオンなどを参考に作成したセキュリティ系のリソースなどです。
そういった前提がある中で、既存AWSリソースの確認方法としては3点やっています。まずTerraformのコードを眺める。Terraformには一覧を出力するterraform state listというコマンドがあり、それも活用しました。
また、前述のドキュメントを読んだり、マネジメントコンソールにログインして画面を参照することもやりました。リソース間のつながりである、VPCとかサブネット、ルートテーブルとか、セキュリティグループと各リソースとか。そういったつながりを追っていくことは、自分としてはマネジメントコンソールが向いていたので、それも活用して確認をしました。
既存AWSリソースの確認作業時に意識したことは、作業時間を有効活用するために漫然と各リソースの存在有無や設定を見るのではなくて、セキュリティ的な問題有無がどうかを強く意識して確認をしました。
（スライドを示して）後述するOrient、状況判断を一部先行実施したかたちにはなりますが、こちらに箇条書きで記載しているような点について、問題がないかを確認しました。
いったん全部のリソースを舐めてから、「じゃあセキュリティはどうなんだっけ」と確認すると二度手間になってしまうので、「（スライドに記載の）こういったセキュリティはどうか」ということを意識しながらリソースを見ていきました。
Observeのステップ3：構成図の作成
Observeの3つ目が構成図の作成です。背景は、既存の構成図はありましたが、全体像を見渡すのには十分ではありませんでした。VPC以外のリソースの記載がなかったり、VPC内のリソースも一部記載が欠けていました。
ここで構成図を作成する意義や目的についてちょっと触れたいです。構成図を作るのはコードを書くのとはまた違い、ドキュメンテーションに類するものになるかなと考えています。
こういったドキュメンテーションもエンジニアリングであり、SRE本とかではよく出てくるToilとかでは無いかなと。ちゃんと立派なエンジニアリングだということと、今回は現状把握のために構成図を作成するわけですが、関係者との今後の情報共有においても価値があることだと考えています。使い捨てというか、その場限りのことではなくて、先々にわたって価値のある行動になると思っています。
例えば、将来新しいSREメンバーがジョインしてくれた時のオンボーディングにも役に立つでしょう。AWS JapanのSAさんに何か相談をする時にも、恐らく「構成図を見せてください」と言われるんじゃないかと思いますが、そういった時にもパッと出せるということで、構成図の作成もやりました。
Orient、状況判断
次にOODAループの2つ目のステップのOrient、状況判断に入っていきます。ここでは、リスクの高い脅威から早期に対応していくために、優先付けの判断軸を「事業の存続を揺るがすレベルのインシデント」が発生しそうかどうかとしました。
具体的には以下5点になります。アカウントの乗っ取り、機微情報の流出、データの喪失、システムダウン、Webページの改ざんです。
ここで出している5つは、先ほどのSTRIDEみたいに何かのフレームワークでうたわれているものではなくて、これまでの自分の経験だったり、前職で得られたナレッジであったりから導き出したものになっています。OODAループでは、過去の経験も十分に判断軸としていいと言われているようです。
（スライドを示して）Orient、状況判断が続きますが、Observeによって得られたデータに、先ほどの判断軸を掛け合わせて導き出したのがこちらです。
今回は表形式で見せています。まず一番左の列を見ていただきたいです。観察によって得られたデータの2つ、各開発者がIAMユーザーを使用しているということと、EC2でIAMユーザーを使用しているということ。
「EC2がIAMユーザーを使用しちゃっていました」というところで、ここに対する想定インシデントとしてはアカウント乗っ取りがあると思っています。理由は、アクセスキーのような永続的な認証情報が存在するので、流出してしまった時には被害が大きいです。
残り3点目、4点目はS3です。3点目は、S3は全部非公開状態ではありましたが、ブロックパブリックアクセスが有効ではなかったので、将来の誤設定によって機微情報が流出することが考えられる。最後は、一部のS3のバージョニングが有効ではないので、将来の誤削除によってデータが喪失してしまうことが考えられました。
Deside、意思決定
そしてOODAループの3つ目。Deside、意思決定ですが、リスクが高く、優先的に対応すべき脅威に対して具体的な対応内容を決定しました。（スライドを示して）一番右側に記載していますが、AWS SSOの導入、IAMロールの使用、そしてS3の設定を、あるべきかたちに有効化するといったものです。
Act、行動
最後にAct、行動です。先ほどのDecideで採択された方針に基づいて、実際に行動します。ここに関しては現在進行中ではありますが、AWS SSOの導入は完了しているので、これについて少しお話ししたいと思います。
AWS SSOを導入してみた所感とTips
AWS SSOを実際に導入してみての所感やTipsについて、2ページにわたってお話しするので、これから導入を考えている方は参考にしていただけたら幸いです。
まず初期設定周りです。弊社はGoogle Workpspaceを使っています。Google WorkpspaceとAWS SSOを連携させる場合の手順についてはAWS公式ブログにすごく詳しく載っているので、そちらが非常に参考になると思っています。30分〜40分程度で簡単に完了します。
次に、Google Workpspaceでの初期エラーにちょっと注意したほうがいいということがあります。いったん初期設定で正しく設定しましたが、検証でSSOを利用したところ、Google側で403エラーが常に発生するという事象がありました。
数時間後には発生しなくなったので、初期設定をした後はこのエラーが出るということを念頭に置いて、1日置いてみて作業を再開したほうがスムーズでいいかもしれません。
次に導入した後の話です。AWS SSOでのAWS CLIの利用は、非常に簡単・快適です。aws configure ssoで、profile名というかたちで初期設定します。その後にaws sso login、profile名というコマンドを叩くと、ブラウザが起動してワンクリックで認証が完了します。
過去に利用したほかの方式だと、6桁のパスコードが書かれたSMSをスマホで受信する待ち時間とかが微妙に発生したんですけれど、そういうイライラもなく、非常に簡単に認証が完了するので快適でした。
最後にTerraformを使っている方向けのTipsです。AWS SSOにはユーザーやグループという概念がありますが、残念ながらTerraformでの作成には非対応なようなので、マネジメントコンソールで作成する必要があります。
続いて許可セットというものがあります。ポリシーのようなものです。ドキュメントによっては“権限セット”という和訳をしていますが、同じものです。あとはAWSアカウントと許可セットとSSOグループをひも付けるような情報を作ってあげる必要がありますが、これはTerraformで作成可能です。
（スライドを示して）こちらに記載しているterraform-aws-ssoというTerraformのモジュールがあります。これを使うと必要なリソースが一気に作れる、かつ、直感的に作れるのではないかと思うので、ゼロから構築する場合はこれを使うと便利なのでおすすめです。
よかった点・懸念点の振り返り
振り返りに入っていきます。まずよかった点ですが、今回OODAループという考え方を採用したことで、事業リスクの高い脅威への対応を早期に着手できたんじゃないかなと考えています。
またObserve、観察というステップを経て、自社のワークロードに対する理解が深まったので、もう1度OODAループを回す時にも、より精度の高い状況判断・意思決定ができるんじゃないかなと考えています。
懸念点としては、Observeでの収集データが実は不十分で、よりよいDecide、意思決定ができていないかもしれない。Orient、状況判断での判断軸が不十分で、よりよいDecide、意思決定ができていないかもしれないという懸念が残っているかなと思っています。
そういった懸念点を踏まえて今後改善していきたい点です。AWS Well- Architectedのセキュリティの柱を見ると、AWSを使っている場合に、どういったセキュリティを向上させるためにどんなアクションを取ればいいかという具体的な内容が載っているので、そこを参考にしたり。
あとはSecurity Hub、IAM Access Analyzer、Inspectorなどを導入して、Observe、観察だったりOrient、状況判断をより充実させて、精度の高いものにしてセキュリティを向上させていきたいと思っています。あと弊社はマルチアカウントを使っているので、Control Towerも使っていきたいなと思っています。
AWS SSOはすべてのスタートアップにおすすめ
最後にまとめです。ベストプラクティスは、脅威モデリングの実施というところは触れておきたいと思います。今回は時間の都合というか、状況を鑑みて、脅威モデリングをちゃんとやるところは見送りました。
セキュリティ向上のためのベストプラクティスとしては、IPAとかAWSさんの資料にもあります。これはベストプラクティスなので、ぜひ検討してください。AWS BlogだったりAWS Builders Online Seriesにわかりやすく網羅的に書かれているので、ぜひご覧になってみたらいいんじゃないかなと思います。
2点目に、今回OODAループを紹介しました。不確実性の高い状況で物事を進めるのに適しているプロセスになります。セキュリティに限った話ではないので、もし知らない方は、今回ちょっと頭の片隅に置いておいて、先々こういったOODAループという考え方を当てはめて行動してもらえたら幸いです。
最後がAWS SSOについてです。Organizationsが使えるのが前提にはなりますが、すべてのスタートアップにおすすめしたいと思っています。
例えばエンジニアや社員がGoogleアカウントを使っている状況であれば、退職したらそのGoogleアカウントを削除すると思います。自然とAWSも使えなくなったりするかたちで退職時のフローやセキュリティの向上にも役に立つし、非常に便利なのでおすすめです。
発表は以上です。ご清聴、ありがとうございました。
