AWS Startup ブログ

【開催報告】AWS Startup Tech Meetup Online #9 – Security

（この投稿は AWS Startup Community から寄稿頂いたものです。内容は Zenn に投稿されている記事と同一になります。）

こんにちは、あつぽんと申します。普段は、スタートアップで Web サービスの開発（インフラからフロント）、趣味で VR/AR をやったりしています。
本記事は、11/9 に行われた AWS Startup Tech Meetup Online #9 – Security の開催報告です。

オープニング

AWS Startup Community の紹介

最初に、本ミートアップを主催されている、AWS Startup Community の紹介がありました。
AWS Startup Community は、AWS を利用しているスタートアップのためのコミュニティです。技術情報だけでなく、アーリーステージなどのスタートアップ特有（実際の泥臭い実務から採用といった非技術分野）の情報や知見の共有、スタートアップへの露出機会の提供等を行っています。

Security Roadshowの開催

本ミートアップに関連して、クラウドセキュリティに関するセッション、ハンズオンが行われる SecurityRoadshow 2021 が 11/11～12 にかけて行われました。内容についてはこちらから確認できます。

知らなきゃ損！AWS Activate “限定オファー” のご紹介

AWS が提供されているスタートアップ企業支援プログラム「AWS Activate」支援策拡張について、アマゾン ウェブ サービス ジャパン合同会社の松田さんからご紹介がありました。

現在、AWS 10 の Startup 支援プログラムとして以下のような支援策がありますが、今回はそのうち AWS Activate に関する紹介となります。

AWS Activate には、自己資金で事業を行っているスタートアップ向けの Activate Founders と、資金調達やアクセラレーションプログラム参加をしているスタートアップ向けの Activate Portfolio があります。

AWS Activte は、専用のポータルサイトが AWS Console 経由で入ることができ、クレジットの残高確認やコスト最適化プランの表示等が行えますが、そこから限定オファーの申し込みもできます。今までも、グローバルで 100 を超える Activate 協業パートナーからサービス料金のディスカウントやクレジットなどを提供してもらっていましたが、新たに日本の協業パートナーが参画しました。さらに、今後パートナーを順次拡大していくのでぜひ AWS Activate への参加を検討いただければとのことでした。

特別対談：リソースの少ないスタートアップにおけるセキュリティへの向き合い方

今回は、株式会社アスタリスク・リサーチの岡田良太郎さんと、アマゾン ウェブ サービス ジャパン合同会社の齋藤祐一郎さんによる特別対談が行われました。岡田さんは、企業のガバナンスの強化や企業成長させる中、どのようにプライバシー、セキュリティの要求を実現していくかについてハンズオンやアドバイザリーを行っており、斎藤さんはアーリーステージのスタートアップ向けの技術支援を担当しているとのことで、実際にスタートアップ内で活躍されている方々です。

対談のテーマとして以下の3つが取り上げられました。

1. セキュリティ対策　何から始めるか・・・安全な実験場

動くものをさっと作り市場に出し、フィードバックをかけるループをなるべく早く回したいスタートアップにとって、セキュリティリスクを洗い出したいといっても聞く耳を持つ人は少ないと思います。
その中で意識として持ちたいのは、セキュリティのことを考えるのは最低限安全な実験場を作るということです。たとえば、大きな会社の社内ベンチャーのような環境でサービスを作ろうとしたときに、すでに動いているサービスにまで影響を与えてしまうと大きな問題になってしまいます。そのようなとき、影響範囲が新たに開発している部分だけであれば問題は大きくならずにすすめることができます。

新規サービスや DX を進めていくに当たり、以下のような段階を踏むことが多いのではないかと思います。この段階は、何か間違えたときに謝る人数の増え方とも言えます（ユーザーの規模）。

  1. プロトタイプの挑戦（アドホックが当然）
  2. 仕組み化導入の挑戦（ユーザ・部門は限定的）
  3. 組織的展開と発展への挑戦（入れ替えを見据えた組織展開）

このプロセスを進めていくに当たって、全力で走りたい車（サービス）にとってのガードレールを作ることがセキュリティの役割といえ、セキュリティを考えていく第一歩は、開発メンバーがやれることを決めれること、その範囲内で安全に実験ができる環境を構築することが挙げられます。

具体的には、初期のスタートアップでは巨大な権限を持つ IAM を作りがちですが、AWS のベストプラクティスページを利用してアカウントを整理することで大分セキュリティが向上すると思います。

その後、安全な実験場を安全であり続けることが大事です。つまり、何らかの権限違反が起こったときに対応するためのモニタリングが次のフェーズで必要とのことです。
ちなみに、大企業でも今でもアカウントとパスワードを使い回してるところもあるそうです、、

世間で実際に起きているセキュリティリスクの TOP10 を OWASP と呼ばれるアプリケーションセキュリティ検証基準を策定している団体が公表しています。今年の重大セキュリティリスクで A01: アクセス制御の不備、A05: セキュリティの設定ミスが上げられていますが、AWS に関して言えば、グループポリシーと IAM で改善できます。

2. セキュリティの実践体制・・・採用と育成

スタートアップでシリーズのいつでセキュリティ人材を採用すればいいのかといった問い合わせが多いですが、セキュリティだけを独立した人材とするのは無理があります。
オススメとして、事業の柱を担当している人がセキュリティを担当するのが有益なのではないでしょうか。現場で動いてる人たちが学んで自衛しないとセキュリティの向上はできなく、CISO とかを呼んできたからといってセキュアな企業になるわけではないからです。
上手くいっている企業は、アドバイスを受け入れる事に貪欲になっている会社の方が多いとのことでした。

3. これからセキュリティどう取り組む？

スタートアップは人が変わることが前提にあり、全体の仕組みやソースコードはなるべく共有されてること、誰かがやめたからといってブラックボックス化しないようにすることが大事です。
後は、アジャイルなどを理解していないボードメンバーが障害になっていることがそれなりにあります。作るものだけじゃなくて生産に関する技術や人に予算を付けられるようになると強いのではないかと思います。
属人性の排除というよりかは、情報非対称性の排除を行い、CI/CD を回し開発の Agility を高めていくのが良いのではということでした。

質疑応答

Q. セキュリティに関して最終的にケツを持つ専任者は？
A. スタートアップにおいてセキュリティの最終責任者は社長なのでは。管理、推進するという意味ではプロダクトマネージャーになると思う。よくプロダクトマネージャに強く支援をしている。

Q. Web アプリ開発の場合 PoC の段階からセキュリティホールを作らないように開発するのが良いでしょうか？ある程度上手くいった段階でケアする方が良いでしょうか？
A. 機能をどんどん試している時に同時にセキュリティを考えるのは難しい。1つのイテレーションの最後（週1とか）でセキュリティに関するテストを回して対応するなどしていくと良いのでは。セキュリティーホールを作ってはいけないと言うよりも、それが入り込まないようにすることが大事だと思う。

Q. セキュリティを学ぶオススメのロードマップがあればご教授頂きたい
A. OWASP TOP 10 をまずは見てみてください。

Q. AWS サービスの中でセキュリティ違反に気づける仕組みは何があるでしょうか。Trusted Advisor は知っているのですが、それ以外に何かあれば教えて頂けると幸いです。
A. Trusted Advisor 以外には、AWS Control Tower を設定し、AWS SecurityHub を立ち上げると、自分達の設定を評価することができる。BlackBelt Online セミナーで詳細を説明することもある。

まとめ

大事なのはセキュリティに関して自分達でちゃんと取り組むことだと思っています、セキュリティが怖いと新しくおもしろい事が作れないと思う。
全速力で走るためのガイドレールがセキュリティだと認識して、走る速度に応じて対応をしていけばいいのではないかなと思う。

AWSマルチアカウントのセキュリティ通知集約（資料）

続いて、株式会社justInCaseTechnologies の富松広太さんからマルチアカウントのセキュリティ通知集約について発表がありました。富松さんは、以前のイベントで justInCase の方と知り合い、今はパートタイムで所属されているとのこと。
justInCase 社では、取引先に大手保険会社が多く、彼らからセキュリティ基準の遵守が求められるため、セキュリティ周りも積極的に対応しているとのことです。

今回実装した通知集約の全体の考え方として、可能な限りマネージドサービスに身を任せ、足りない部分のみリソースを追加するということを意識しているとのことでした。

まず、Control Tower を有効化し以下することで以下が可能になります。

  • 管理用のアカウントが生成され、LogArchive Account にログが集約される
  • 各サービスの AWS Config のルール違反の集約も行える
  • マルチアカウント環境のベースを構築してくれる

続いて、Security Hub, GuardDuty, Organizationsの設定を行い、以下のような対応を行ったとのことでした。

  • audit アカウントに権限委譲し、audit アカウントに結果が集約される
  • Security Hub を有効化すると、AWS Foundational Security Best Practices standard と CIS AWS Foundations Benchmark standard が有効化されて、結果が Security Hub に集約される
  • リソースレベルで例外を設定したいケースがあったため、Security Hub 上の workflow status を suppressed（抑制）に設定
  • Security Hub だけでカバーできない検査ルールを追加
  • リージョン間の通知を Security Hub に集約して Slack へ通知

SSO も導入したが、作業中のアカウントが分かりにくかったので、chrome 拡張（色指定や、AccountAlias を表示）をメンバーが作ってくれました。

Chrome 拡張機能 : AWS Peacock Management Console

質疑応答

Q. スタートアップの規模で、Audit Account をサービスアカウントから個別に分離する必要性は感じますか？
A. サービスアカウントから Audit Account を切り分けること自体は Control Tower を使うことで可能。切り離しておけば、IAM の設定で分けることができる。後から切り離すのは大変なので先にやっておいた方がいいのでは。

Q. サービスで利用していないリージョンでも Security Hub 等有効化していますか？
A. ベストプラクティス的には有効化を勧めているが、予算等の問題もありサービスで利用していないリージョンは Security Hub は有効化していないです。

Q. 個別のセキュリティルールの選定についてはどのように決めていますか？
A. 有効化するチェックについては、お客様から求められたモノを対応している。それに加えて、やっておいた方がいいのではと話が上がったものは追加している。

暇だしDevSecOpsやってみた / CodePipeline Now and Then（資料）

続いて、LayerX の Suzuki Kengoさんから、開発初日からリリースまでどのようにデプロイをしていったかについて話がありました。
Suzukiさんは、現在 三井物産デジタル・アセットマネジメント株式会社に出向されており、Fintech 分野のオンライン投資サービスの開発に携わっています。

セッションでは、バックサイド部分について初期構想から現在までどのようにメリット、デメリットを精査して進めていったかについて説明がありました。

このように移り変わっていく中で、妥協した部分もあるそうですが、最終的なユーザーへ価値を最速で届けるという目的では問題ないため、今後も改善を続けていきたいとの事でした。

質疑応答

Q. 徐々に良い運用方法が実現されていったようですが、運用方法を変更するコストや大変さの感触を教えて頂けると幸いです。
A. エンジニアは GitHub へ Push してマージされるまでがメインで考えており、切り分けられてる。そのため、運用方法については基本的には自分だけの工数で考えられていて、工数としては、下がっている。
パイプラインが変わる際には、その度にインフラのデザインドキュメントを用意して、どのような考えを持っていくかを用意してチームへ共有している。

“Baseline Environment on AWS (BLEA)” のご紹介（資料）

最後に、アマゾンウェブサービスジャパン合同会社の大村幸敬さんから Baseline Environment on AWS(BLEA) テンプレートの使い方の紹介がありました。

AWS は Builder を支えるプラットフォームなため、適切な箇所で適切なツールを使えるようにしていることが強みです。ただし、セキュリティをきちんとしていこうとした場合、ツールの事前承認だと管理業務がボトルネックとなってしまいます。そのため、各システムを自由に使わせる一方で、Builder を守るためのガードレールを用意する事が必要になっています。

ガードレールの役割を担うテンプレートを配布すれば一定のレベルが用意できるのではと考えました（テンプレートによるガバナンスの考え方）。
また、配布がコード量が多くなりがちな CloudFormation ではなく、Cloud Development Kit (CDK) で行うことで、短めのコードで継続的にメンテナンスができることが特徴としています。このような考えで共有したのが BLEA です。

テンプレートには、シングルアカウントとマルチアカウント用があり、アーキテクチャは以下のようになっています。

BLEA は AWS Japan の SA が開発・メンテナンスしています。ユースケースの拡張やセキュリティサービスへの対応強化を行う予定です。
今後は BLEA や CDK を利用するための解説資料やハンズオンを予定しています。詳細な説明についてはブログでも公開しているので是非ご覧ください。

質疑応答

Q. CIS-bench と AWS Security Foundation はどのように使い分けるのが良いでしょうか？両方必要な場合はどういったケースでしょうか？
A. 現在の BLEA の思想として、独自の考えを持ち込まず、AWS の各サービスの挙動に合わせているため、両方とも有効化している。最近は、AWS foundational Security Best Practice のアップデートが多いためこちらの方がよいのでは？

Q. 既存の Organization で使っている Config や CloudTrail を off にしなくても Control Tower に移行できるようになる予定はありますか？
A. ご要望はたくさん頂いています。先のロードマップについては話せないが開発チームに情報共有しておきます。

アーカイブ

こちらで本ミートアップのアーカイブがありますのでご興味ある方はぜひご覧ください！

参加した感想

今回、セキュリティ対策について自分達以外の様子を聞けたのが大変参考になりました。重要な考え方として、「全速で走るためのガードレールを作る」が刺さりました。自身でも「セキュリティはちゃんとしないといけないけど、、」と心の中で煮え切らない点もありましたが、今回のミートアップで思考が整理できました。まずは、IAM Access Analyzer で肥大化した IAM ロール設定から見直します、、
本ミートアップを開催して頂きました AWS Startup Community の皆さま、ありがとうございました！

このブログポストの著者（寄稿者）

あつぽん

スタートアップで AWS を使った Web サービス（インフラからフロント）、機械学習、趣味で AR/VR をやっています。

Twitter: @atupon