手間をかけすぎず、なるべく楽にセキュリティ対策を行うために　AWSで作成したWebアプリ運用で攻撃されやすいポイント4つ

自己紹介

黒曜氏：「なるべく楽したいAWSセキュリティ」と題して、Leaner Technologiesの黒曜が発表します。よろしくお願いします。簡単に自己紹介をします。黒曜です。スライドのアイコンと@kokuyouwindというアカウント名で、TwitterやGitHubにいます。名古屋に住んでいて、今も名古屋の自宅からリモートで登壇しています。

Leaner Technologiesというスタートアップの会社は東京にあって、私はフルリモートで名古屋から働くかたちで参加しています。職種はRailsエンジニアですが、最近はNext.jsでフロントやAWSの設定もしています。

Leaner Technologiesの紹介をします。「調達活動を、ぐっとスマートに。」として、調達領域、会社が物を買うことにおいて非効率なこと、（例えば）電話をかけて見積りを取ったり、FAXを送ったり、返ってきたものをExcelに手で入力して「ここが安い」と比較していた部分を、デジタル化したりして効率化しようとしているスタートアップです。

（スライドを指して）このようなメンバーでやっています。たくさんいますが、実はこの中にエンジニアは5人くらいしかいなくて、ビジネスメンバーがすごく多い組織です。最近はエンジニアをどんどん増やしたくて積極的に採用しているので、よろしくお願いします。

AWSのセキュリティを楽をしつつ安全に行うためには？

本題にまいりましょう。AWSのセキュリティといえばいろいろあります。IAM権限を絞るとか、GuardDutyとか。SecurityGroupでも設定するし、「たくさんあって何からやればいいのかよくわからない」と思うことがあるのではないでしょうか。私はありました。

何をどこまでやればいいのか考えるけど、そんなに手間をかけたくない。怖いから安全にはしたい。とはいえ、手をかけ過ぎずなるべく楽をしたいので、どうにかして楽できないかと考えた内容を発表します。

どうやって安全に楽をするか。先にある程度まとめを言ってしまうと、結局AWSのベストプラクティスに従うのが一番ですが、ちゃんと従えているかをチェックするために「Security Hub」というサービスを使うのが1つ。また、そもそも気にするポイントが減るので、なるべく持ち物を減らす。ほかに、ツールを使って既定値に合わせることで、自分で設定する範囲を減らしています。

例えば、Fargateを使ってEC2のインスタンスを持たずに、なるべくコンテナ化していく。ネットワークの環境構築も手でやると大変なので、Copilot CLIに任せる。さらに、アプリケーションのレベルでもAWSサービスで、例えばWAF（Web Application Firewall）で典型的な攻撃を防ぐとか、ECR（Elastic Container Registry）のコンテナスキャンで脆弱性をチェックするとか、いろいろ使えるものがあるので、これらを使って楽をしながらなるべく安全に運用したいという話をします。

対策が必要な4つの攻撃されやすいポイント

今回のアジェンダです。最初にセキュリティのレイヤー。大雑把にどういうセキュリティのポイントがあるのかという分類の話をしてから、AWSアカウント、ネットワーク、Webアプリ、データストアというレイヤーそれぞれについて話して、最後にまとめようと思います。

最初は「セキュリティレイヤーの分類」です。“セキュリティレイヤー”（という用語）は、いい言葉がなかったので適当に作りました。たぶん正式な用語ではないので、そこだけお目こぼし願います。

AWSでWebアプリを作って運用する際に、どんなポイントが攻撃されそうなのかを考えてみます。（スライドを指して）AWSでWebアプリを作るとこんな感じという、すごくざっくりしたものを描きました。

まず、AWSのIAMでいろいろなリソースを作って環境を構築していきます。ユーザーからのアクセスは、まずロードバランサのALB（Application Load Balancer）で受けて、そこから内部のアプリケーションサーバー、EC2やECS（Elastic Container Service）で立ち上がっているところに行って、データストアのRDS（Relational Database Service）やS3に書き込んだり読み込んだりする動きになると思います。

この中でどこが攻撃されそうかを考えると、一番ヤバいのはIAMです。IAMを不正利用されるとリソースをなんでもかんでもいじられるし、すごく料金がかかるかもしれないし、ウイルスも仕込まれるかもしれない。悪用し放題なので、ここが一番ヤバいポイントです。

次に、ネットワークです。VPC（Virtual Private Cloud）の中にEC2を置いているはずですが、そこにうっかり入られるとサーバーの中でなんでもできるので、ウイルスを設置したり、データを盗用できたりします。

次に、Webアプリ自体の脆弱性です。VPC自体に穴はないけれど、正規のルートのALBから入りSQLインジェクションを流し込むことによって、データを盗用するような攻撃があり得ます。

最後のデータストアについては、RDSであればVPCの中にいるので、VPCに穴がなければ大丈夫のはずですが、例えばS3がグローバルに公開されていると直接アクセスできてデータ盗用があり得ます。

大まかに、これら4つの攻撃ポイントがあるのではないかと思います。これ以外にも考えればあると思いますが、少なくともこれらは確実に対策が必要なので、ここからはこの4つの話をしようと思います。

AWSアカウントのセキュリティのベストプラクティス

まず、AWSアカウントのセキュリティです。使い始める時の設定は重要ですが、結局のところ、AWSアカウントの初期設定はベストプラクティスに従うのが確実だと思います。ベストプラクティスがどこにあるかというと、個人的には「DevelopersIO」の記事がすごくわかりやすくまとまっていると思うので紹介します。

（スライドを指して）こちらは『AWSアカウントを作ったら最初にやるべきこと 〜2021年版〜』という記事です。この中に、「この設定は絶対にやるべきだ」とか「理由がなければやったほうがいい」という一覧があるので、これに沿って設定すればおおむね間違いはないと思います。

https://dev.classmethod.jp/articles/aws-1st-step-2021/

ほかに、同じくDevelopersIOの『AWSセキュリティ対策全部盛り』という記事では、一番簡単なやり方から上級者向けまで、いろいろなパターンの「ここをやれ」というものがまとまっているので、ざっと目をとおすといいです。

例えば「必要なサービス有効化」ではGuardDutyを有効化するといい。Well-Architectedフレームワークは取っかかりのないまま読むと大変だけど、「こう読むといい」というアドバイスがあるので、すごくいい記事だと思います。

https://dev.classmethod.jp/articles/aws-security-all-in-one-2021/

人の記事を使って紹介していますが、それだけでなく弊社でやっている話もします。ベストプラクティスに沿って設定するのはいいんですが、本当に設定しきれているのか、あるいはその後足した設定がベストプラクティスに沿っているのか不安な部分は、「Security Hub」というサービスを使って設定状況をチェックしています。

（スライドを指して）Leanerのセキュリティスコアはこのように見られます。弊社で有効にしているセキュリティ基準では、AWS基礎セキュリティのベストプラクティスを有効にしています。これでセキュリティスコアが80パーセントになっている。

（その）下に、重要度ごとの検出数が出ています。「おいおい、80パーセントかよ。セキュリティスコア100パーセントじゃないの？」と思われるかもしれませんが、重要項目の中に「ルートアカウントを物理MFA（Multi-Factor Authentication）デバイスでロックしろ」というものがあるんです。

ただ、リモートワークだと物理MFAデバイスでのアクセスのハードルが高くて、ルート封印だけとはいえ、アカウントを作るたびにオフィスに置いてあるMFAデバイスの設定を誰かにお願いするようなボトルネックになるのは避けたい。今は1Passwordの仮想デバイスでMFA設定をすることにしているので、これについては漏れてしまっています。

「重要度：中」以下については、個別に対応するかどうかを検討するようにしています。この後に紹介しますが、Copilot CLIで作ったリソースが引っかかってしまうこともあります。それらはCloudFormationをいじらないといけないし、不整合が起こる可能性があるので、リスクが低ければ見送っています。

また、ログを出すようにする系のものも、全部出すとコストがかさむので、特にCloudWatchに流すものは見送っています。S3ならそんなにコストがかからないのでいいとは思います。以上の理由で、100パーセントにはなっていません。

もう1つのベストプラクティスは「環境ごとにAWSアカウントを分ける」です。開発環境は開発者が自由に使えないと不便ですが、本番環境はしっかり分けて権限を絞っておくことで、誤操作やアカウントを取られてしまった時の悪用リスクを低減できるようにしています。

構成としては、開発環境、ステージ環境、本番環境の各アカウントを分けた上で、中央アカウントからAWS SSOをして、各環境にシングルサインオンするようにしています。

SSOを直接使っていて、Control TowerというSSOなどのセキュリティのガードレールを設定してくれるものがあることは知っていて、「使わないの？」といわれることもあります。これらは私が入社してまだ1年未満で、サービスを立ち上げる際にアカウント整備する部分だったので、徐々に設定増やしていきたいとは思いますが、今回は未導入です。

経験則として、実際に個別のものを触っていない状態でControl Towerみたいな統合系のサービスをやってしまうと、トラブルシューティングが大変になる。SSOなど自分が未使用だったものがいくつかあるので、それらに個別に触ってから統合サービスを入れていこうと考えています。

次に新しいAWSアカウントを作る前には移行しておきたいと思っています。権限関連も今は最低限の分類しかしていないので、その時に合わせて見直したいと思っています。AWSアカウント周りの取り組みについては以上です。

（次回に続く）