AWS Startup Tech Meetup Online #9 - Security 開催報告
こんにちは、あつぽんと申します。普段は、スタートアップで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つが取り上げられました。
セキュリティ対策 何から始めるか・・・安全な実験場
動くものをさっと作り市場に出し、フィードバックをかけるループをなるべく早く回したいスタートアップにとって、セキュリティリスクを洗い出したいといっても聞く耳を持つ人は少ないと思います。
その中で意識として持ちたいのは、セキュリティのことを考えるのは最低限安全な実験場を作るということです。たとえば、大きな会社の社内ベンチャーのような環境でサービスを作ろうとしたときに、すでに動いているサービスにまで影響を与えてしまうと大きな問題になってしまいます。そのようなとき、影響範囲が新たに開発している部分だけであれば問題は大きくならずにすすめることができます。
新規サービスやDXを進めていくに当たり、以下のような段階を踏むことが多いのではないかと思います。この段階は、何か間違えたときに謝る人数の増え方とも言えます（ユーザーの規模）。
- プロトタイプの挑戦（アドホックが当然）
- 仕組み化導入の挑戦（ユーザ・部門は限定的）
- 組織的展開と発展への挑戦（入れ替えを見据えた組織展開）
このプロセスを進めていくに当たって、全力で走りたい車（サービス）にとってのガードレールを作ることがセキュリティの役割といえ、セキュリティを考えていく第一歩は、開発メンバーがやれることを決めれること、その範囲内で安全に実験ができる環境を構築することが挙げられます。
具体的には、初期のスタートアップでは巨大な権限を持つIAMを作りがちですが、AWSのベストプラクティスページを利用してアカウントを整理することで大分セキュリティが向上すると思います。
その後、安全な実験場を安全であり続けることが大事です。つまり、何らかの権限違反が起こったときに対応するためのモニタリングが次のフェーズで必要とのことです。
ちなみに、大企業でも今でもアカウントとパスワードを使い回してるところもあるそうです、、
世間で実際に起きているセキュリティリスクのTOP10をOWASPと呼ばれるアプリケーションセキュリティ検証基準を策定している団体が公表しています。今年の重大セキュリティリスクでA01:アクセス制御の不備、A05:セキュリティの設定ミスが上げられていますが、AWSに関して言えば、グループポリシーとIAMで改善できます。
セキュリティの実践体制・・・採用と育成
スタートアップでシリーズのいつでセキュリティ人材を採用すればいいのかといった問い合わせが多いですが、セキュリティだけを独立した人材とするのは無理があります。
オススメとして、事業の柱を担当している人がセキュリティを担当するのが有益なのではないでしょうか。現場で動いてる人たちが学んで自衛しないとセキュリティの向上はできなく、CISOとかを呼んできたからといってセキュアな企業になるわけではないからです。
上手くいっている企業は、アドバイスを受け入れる事に貪欲になっている会社の方が多いとのことでした。
これからセキュリティどう取り組む？
スタートアップは人が変わることが前提にあり、全体の仕組みやソースコードはなるべく共有されてること、誰かがやめたからといってブラックボックス化しないようにすることが大事です。
後は、アジャイルなどを理解していないボードメンバーが障害になっていることがそれなりにあります。作るものだけじゃなくて生産に関する技術や人に予算を付けられるようになると強いのではないかと思います。
属人性の排除というよりかは、情報非対称性の排除を行い、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マルチアカウントのセキュリティ通知集約
続いて、株式会社justInCase Technologiesの富松広太さんからマルチアカウントのセキュリティ通知集約について発表がありました。富松さんは、以前のイベントでjustInCaseの方と知り合い、今はパートタイムで所属されているとのこと。
justIncase社では、取引先に大手保険会社が多く、彼らからセキュリティ基準の遵守が求められるため、セキュリティ周りも積極的に対応しているとのことです。
今回実装した通知集約の全体の考え方として、可能な限りManagedに身を任せ、足りない部分のみリソースを追加するということを意識しているとのことでした。
まず、Control Towerを有効化し以下することで以下が可能になります。
- 管理用のアカウントが生成され、LogArchiveAccountにログが集約される
- 各サービスのconfigのルール違反の集約も行える
- マルチアカウント環境のベースを構築してくれる
続いて、Security Hub GuardDuty + Organizationsの設定を行い、以下のような対応を行ったとのことでした。
- auditアカウントに権限委譲し、auditアカウントに結果が集約される
- Security Hubを有効化すると、AWS bestpracticeとCIS Standardが有効化されて、結果がSecurityHubに集約される
- ただし、Check数が多いため確認が煩雑になったり、AWS bestpracticeとCIS Standardで重複するチェックがあるため、Security Hub standardの不要なチェックを排除するようにしたとのこと
- リソースレベルで例外を設定したいケースがあったため、Security Hub上のworkflow statusをsuppressed（抑制）に設定
- SecurityHubだけでカバーできない検査ルールを追加
- リージョン間の通知をSecurityHubに集約してSlackへ通知
SSOも導入したが、作業中のアカウントが分かりにくかったので、chrome拡張（色指定や、AccountAliasを表示）をメンバーが作ってくれました。
AWS Peacock Management Console
質疑応答
Q. スタートアップの規模で、Audit Accountをサービスアカウントから個別に分離する必要性は感じますか？
A. サービスアカウントからAudit Accountを切り分けること自体はControl Towerを使うことで可能。切り離しておけば、IAMの設定で分けることができる。後から切り離すのは大変なので先にやっておいた方がいいのでは。
Q. サービスで利用していないリージョンでもSecurity Hub等有効化していますか？
A. ベストプラクティス的には有効化を勧めているが、予算等の問題もありサービスで利用していないリージョンはSecurityHubは有効化していないです。
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の皆さま、ありがとうございました！
アーカイブ
こちらで本ミートアップのアーカイブがありますのでご興味ある方はぜひご覧ください！
Discussion