利用者にAdmin権限委譲しても大丈夫　ニフティがAWS導入時から行ってきたマルチアカウント管理法

ニフティがAWSをどう管理しているか

石川貴之氏（以下、石川）：「AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと」という題でお話しします。まずは自己紹介です。

ニフティ株式会社の基幹システムグループにいる石川貴之です。担当業務はAWS/GCPの管理、Atlassian製品の管理、Webサービスのバックエンドを担当しています。

少しだけ会社紹介もしたいと思います。ニフティ株式会社は@nifty光を始めとする、ネットワークサービス事業と、@niftyニュースのようなWebサービス事業。グループ会社で、不動産などの行動支援プラットフォーム事業を営んでおります。「ニフティなんだからニフクラを使っている」と思うかと思いますが、ニフクラもAWSも使っています。

本日は「ニフティがAWSをどう管理しているか」について話していこうと思います。話す内容ですが、ニフティがAWS導入前にしっかり決めておいてよかったこと。導入後に段階的に整えていったこと。おまけで、「なんでこれを採用していないの？」という疑問に答えようと思います。話さないのは、導入前に決めた構成の詳細です。こちらはすでに公開した資料があるので、紹介のみになります。

AWSの管理方針と利用状況

はじめに、管理方針と利用状況についてです。ニフティでは、比較的緩やかなセキュリティを敷いています。利用者に権限委譲をして、アカウントレベルはAdministratorを使えます。本当にやってほしくないものだけ制限したり、危なそうなものは検知して通知したりすることでカバーしています。AWSの進化に期待しつつ、追えるようにしていこうと思っているので、管理方法はAWSの機能だけで完結させようという方針にしています。

利用状況ですが、AWS導入から3年経ちました。200アカウントまで増えています。利用者は240人で、社内の半数が何かしらでAWSを使ったことがある状態です。

AWS導入前に決めてよかったこと

それでは、AWS導入前に決めておいてよかったことについて話します。まず導入前に、どこまでやるか方針を決めました。あとから変更しづらいものは、先にしっかりとした構成にしたい。あとから変更しやすいものは段階的に整えていくことで、最初は速度を優先しました。

あとから変更しづらいものが何かですが、1つ目はAWSアカウントの粒度です。これはあとから変えにくいので、サービス、システム単位で環境ごとに作成しました。理由については以前Qiitaに記事を書いたので、気になる方はそちらを参照してください。

次に、コンソールログインアカウント。放っておくとIAMユーザーが氾濫するのはわかっていたので、IDaaSからログインできるようにしました。こちらも詳細は以前登壇した時の資料があるので、気になる方はそちらを見てください。

粒度を細かくしたので、今度はマルチアカウントへの設定配布も必要です。これはCloudFormation StackSetsに決め打ちしました。CloudFormationで管理しにくいものは、Lambdaを使って入れています。

このように、変更しづらいものは導入前に「これで行くぞ！」と決めて設定しました。この辺りの構成は、今も変わっていません。今も運用で不都合はないので、当時の構成の仕方としては正解だったと思っています。参考までに、アカウントの粒度と役割を図にしたものを載せます。

こちらはIDaaS。OneLoginからコンソールログインしているフローです。

AWS導入前後で整えていった部分

ここまでが、事前に決めて設定したことです。ここからが本日のメインです。導入前後から段階的に整えていった部分を話します。あとから変更しやすいものとして定義した部分。AWS管理における、運用改善と共通セキュリティ設定がそれに当たります。

まずはAWS管理における運用改善。AWSアカウントの払い出しと初期設定についてです。初期設定を手動でやったら、3時間かかってしまいました。アカウント数は100を超えることがわかっていたので、自動化は必須です。そのため、運用開始までに一部自動化して、1時間でできるようにしました。その後も改善していき、最終的にはS3にデータを投げて、20分待てばできている状態にまでもっていきました。

こちらはその構成図です。ワークフロー部分にはStep Functionsを使って作りました。先ほどお話ししたように、CloudFormationで入れにくいものはLambdaを使って入れています。それ以外のほとんどの設定は、CloudFormation StackSetsから入れ込んでいます。そのため、セキュリティ設定の追加や変更を行いたいときは、ここのテンプレートの更新を行う運用になりますね。

参考までに、CloudFormationで管理していないものの一覧です。一度変えたら変えない部分が多いですね。

自動化したと言いつつ、手動のもの残っています。ここはリモートワークと相性がとても悪いので、再検討したい部分ではあります。

AWSの共通セキュリティ設定

続いて、共通セキュリティ設定について話します。初期設定ではStackSetsを使って入れている部分です。まずは、何を設定しているかから。導入初期では、簡単に導入できて、コストに見合うものだけ入れました。この時にGuardDutyがとても頼もしかったです。今はこのように増えたので、増やしたものについていくつか話します。

まずConfigRule。これは導入初期から入れたかったんですが、コストの問題で見送っていました。2019年の8月に値下げされて、これを機に一気に導入しました。今ではコンプラチェックはほとんどこれを使っています。当てているConfigRuleのほとんどはマネージドのものです。CISやControl Towerのものから抜粋して適用しています。

社内で起きた障害の再発防止策として、追加で入れているものもあります。あとは通知を充実させたのが大きい。ここについては、後ほど説明していきます。

設定を入れたところまで話したので、次は集約です。先ほどお見せした、導入時に入れていたものの集約と通知の図です。GuardDutyを集約させたぐらいですね。そこからGuardDutyの通知を増やしたり、Personal Healthイベントの集約と通知を増やしたり、ConfigRuleを増やしたりしました。今ではこうなっています。

マルチリージョンにも対応して、集約はすべてEventBusに集中させ、Lambdaを使って通知を送っています。途中からEventBusに変えたのには理由があります。クロスアカウントでLambdaを使っていると、アカウントの増加でリソースベースポリシーのバイト制限に引っかかるんです。そのため、今はEventBusの構成となっています。

この辺りの構成は、実は他社と似たような構成になっています。不思議とけっこう似通って来るんですね。AWS Configについてもっと知りたい方は、ZOZOさんの過去の資料を見てください。課題や効果については、うちもほとんど同じ内容だったので、今回は割愛して構成だけ紹介します。

AWSの通知

続けて通知について。利用者に通知を送る上で、気をつけたことがあります。アラートが多すぎて見ないことが習慣にならないよう、ここに一番気をつけました。ConfigRuleの設定後に通知を送りたかったんですが、あまりに非準拠が多かったので初期は控えました。まずは管理者として、私がすべての通知を受けて、本当に必要なルールなのか再選定しました。

必要だけど必須ではなかったり、即時対応まで求めなかったりするものもあります。そのため、対応レベルをルールごとに定義して、一定レベル以上のものだけを通知するようにしました。あとは、通知文に何が危険で、何をすればいいのかを書いたドキュメントのリンクも貼るようにしました。こちらが通知例です。AWS Chatbotで送っていた時はアカウントIDだけを教えてくれますが、どこかわからないので、ちゃんとエイリアス名を入れるようにLambdaに書いています。

パターンが多いものは定型文で送っていて、リンク先のドキュメントでカバーしている状態です。ConfigRuleは非準拠になったタイミングでアラートも送っていますが、それとは別に、定期的に非準拠になっているもののリストを通知しています。

こちらが通知のリンク先に設定しているドキュメントです。まだまだ書けていない部分も多いので、改善が必要というか。どんどん書いていこうと思います。

セキュリティまわりでもやりたいことがあるので、これからもどんどんわかりやすく安全に良くしていこうかなと思っています。ここまでで、設定内容の説明はおしまいです。

「どうしてこれを使わないのか？」への回答

最後にサクッと「これ使ってないの？」の疑問に答えようと思います。ちゃんと読みたい方は、公開される資料をあとで見てみてください。

「Control Towerに移行しないの？」……ー運用管理がそこそこ変わり、その工数に見合うリターンが今はないと思っているので見送っています。「なぜOU追加で自動実行されるStackSetsを使っていないの？」……ーOU移行で消されたくないものも、今は一緒のスタックに入っています。それを分離する必要があり、さらに複数のStackSetsがあるので、それを結合する必要もあります。これをやるのがけっこうしんどいので、使っていません。

「なぜSecurity Hub、OrganizationConfigRule、適合パックを使って管理していないの？」……ーそれ1つ使って集中管理できるならいいんですが、たいてい2カ所での管理になるためです。あとは、すでにStackSetsやSCPを使って実現できている部分もあるので、利点が薄いのもあります。

ConfigRuleに関しては、どこで管理すればいいのかをまだ悩み中です。どれに乗れば一番うまい汁が吸えるかを考えていますが、今はちょっと判断しにくいです。

「特に導入してよかったものがあるか」……ー今回の話とはちょっと別になりますが、Masterアカウントのコストエクスプローラーだけを、初期から誰でも使えるようにしたのはよかったです。費用系の問い合わせに対して「ここを見てくれ」ができるのは大きいです。

導入してみて失敗だったものも、いくつかあります。正体不明のリソースをなくすため、自動タグ付けツールを入れてみましたが、IaCと相性が悪かったです。AWS導入を機にIaCも社内で一気に広まって一般化したので、これなら必要ないかと思い削除しました。

ニフティのAWS導入・管理まとめ

長くなりましたが、最後にまとめです。ニフティでは、利用者の成長を阻害しないセキュリティを敷いています。あとから変更しにくい要素は、AWS導入前にしっかり構成を決めたおかげで、3年経った今でも困らず運用できています。時間のかかる新規アカウントの初期設定は自動化して、無理のない運用にしました。初めは速度を優先して、利用状況に合わせて必要なセキュリティを増やしました。

AWSの新機能は都度検証しますが、ROIを考えて導入や移行を決めています。

以上で、ニフティにおけるAWS導入から現在までのAWS管理の話をしました。ご清聴ありがとうございました。

質疑応答

光野：石川さんありがとうございました。それでは質疑応答に移ります。1つ目として「ニフクラとAWSをどう使い分けているか知りたいです」。

石川：ニフクラとAWSはそれぞれ得意分野が違うところもあり、ニフクラで今普通に動いているものもたくさんありますが、AWSにもっていくと逆に高くなるパターンもあります。ニフクラはディスクが強いところもあって。IOをガシガシ使っているものだとニフクラが合っていたり。一概にAWSに全部もっていけば安くなる、使いやすくなるわけでもないので、パターンによって使い分けています。

光野：ありがとうございます。それでは2つ目の質問。「100を超えるAWSアカウントは、結局どのような粒度で作成されていますか？」。

石川：Qiitaにも書いてありますが、主に1サービス、1システムに最低2つ。本番と開発を作るようにしています。サービス単位でもっと分けたいかどうかは、そのサービスの担当者に任せています。大きめのサービスだと、システムごとにprodとdevの両方作ることもあります。

光野：ありがとうございます。それでは3つ目として「セキュリティ通知されたものに対して、実際にアクションしている割合はどんな感じですか？」。

石川：ここは現状、ちゃんと取れていません。緊急性の高いものはちゃんとissue管理していこうとはしています。ただ通知されて、そのあと「なんだこれ？」みたいなものはSlackで見ているので、無視されているわけではありません。

光野：ありがとうございます。ちょうど関連するものがもう1つ。「GuardDutyの結果も、リスクの高いものだけ基幹チーム側でケアされているのでしょうか？その他は利用部門側に任せるのでしょうか？」

石川：GuardDutyはレベルがGuardDuty側で決まっているので、一番高いやつだけ、こちら側でケアしています。

光野：ありがとうございます。それでは次、Control Towerに関する質問が来ております。「Control TowerはLanding Zoneを有効化していないだけですか？　それともまったく利用していないのでしょうか」。こちらはいかがでしょう？

石川：会社ではまったく利用していません。ただ、その設計思想はとてもいいなと思ったので、部分的に参考にして、自前で実装している状態です。Landing Zoneは、分解するとConfigRuleとサービスコントロールポリシーの集合体みたいなものなので、必要なものだけ拝借して、埋め込んだ感じです。Control Tower自体は使っていません。

光野：ありがとうございます。ニフクラに関していくつか質問がきているので、1つか2つ取り上げます。「ニフクラもマルチアカウントできるの？」と質問が来ていますが、こちらはいかがでしょう？

石川：何をもってできるかの定義によりますが、複数アカウントは普通に作れます。それを横断して何かやりたいとなると……。ちょっと私の記憶にはないです。最近ニフクラを触っていなくて記憶が怪しいので、ぜひニフクラの問い合わせ窓口に投げてみてください。最近Terraformにも対応されたので、Terraformからなら、ニフクラもマルチアカウント管理できます。

光野：コストに関する質問も来ています。マルチアカウントでのコスト管理についてです。「RIやSPの購入や管理方法について」。もし話せることがあれば何かお願いします。

石川：弊社では、各アカウントでRIやSPを買う方式にしています。Masterアカウントで買って共有するパターンもありますが、それをすると、どこがどれぐらい使ったのかを再度計算して、このサービスのサーバ費用は実際いくらだったのかを計算して求めないといけなくなるので。そこが大変だったので、各アカウントで買う方式にしています。

各アカウントでどう買うのかは、ベストプラクティス的に「こう買うと安いですよ」というのは一応伝えて、どう買うのかは各アカウントの利用者任せにしています。

光野：ありがとうございます。「StackSetsの内容を更新するときは、各利用部門にメンテ通知を出して一斉にしていますか？」。

石川：メンテ用というか、AWS管理用のSlackチャンネルがあって。そこで告知をして「今回こういう修正を入れます。こういうことを追加して、どれくらい費用がプラスされます。新たにこういう通知が増えます」のようなメンテ内容のページを作って告知して、その時間に（一斉にメンテを）行う。ということを毎回やっています。

光野：ありがとうございます。こちらで石川さんの質疑応答について終了したいと思います。石川さんありがとうございました。

石川：ありがとうございました。