こんにちは。
DSOC Infrastructure Groupの水谷です。*1
趣味は釣りです。
最近、物忘れが激しく本ブログの初稿日すらほぼ忘れてました。
海馬がちゃんと働いているのか不安でなりません。*2
さて、今回はDSOCで新規サービスとして開始されたNews配信システム（以下、News）におけるセキュリティとシステム運用の話をしたいと思います。
このNewsですが、DSOCで既に開発・運用している名刺情報のデータ化システム（以下、GEES)*3とは全く別のシステムです。
新たなシステムの開発・運用ということで、ついでに新たな取り組みをいろいろとしてみました。*4
なんで新たな取り組みをしようと思ったか
なんでかというと、担当することになった瞬間の正直な気持ちが
おじさん、楽したい・・・
だったからですが、もう少しわかりやすくすると、
- DSOCで運用しているシステムの規模、開発案件の数からするとインフラ担当のリソースが足らない
- GEESのセキュリティ施策はシステム規模等を鑑みると現時点では最適と思われるが、Newsにおいては少し大仰な気がした。
もっと理由あったほうがblog書くのは楽だなぁと考えましたけど、あんまり多く並ぶ場合は恐らくもっと根本的な理由があったりするのでこんなものかもしれません。
上記2つも突き詰めれば、当時においては単純に人がたらんかっただけです。
インフラ担当の負担を軽減するためにはセキュリティに手を入れないとということで抜き出してみました。
えっと、今も絶賛募集中です。
jp.corp-sansan.com
では、注意点含めて説明していこうと思います。
問題
リソース不足
開発開始時のエンジニアのリソースはインフラ1名、開発3名、R&D3名です。
あっと、大事な事を言い忘れてました。GEESはインフラ構築とアプリケーション開発は完全分業です。
雑にいうと、開発グループはアプリケーション開発とそれに付随するテストやらサービス運用ツールの作成やらなにやら、インフラグループはインフラ・デプロイ環境・運用監視環境・その他システム運用ツールの構築やらしてます。
こう書くと、開発グループは楽だなぁと思うかもしれませんが、開発規模が大きいのでものすごく大変です。ほんとに。
で、リソース不足からどんなことが予想されたか
- インフラ担当からすると
- 一人で全部のインフラ作るのダルい
- 自分のコードをレビューしてくれる人がいないのは不安
そろそろ渓流の解禁日なんですけど
- 開発担当からすると
- インフラの作業完了を待ってられない
- R&Dからすると
- ヒアリングするのを忘れました。
まぁ、なんでしょう・・・R&Dはおいといても、うまくいく気が1mmもしません。
セキュリティ施策
GEESは結構な大きさです。DSOCの全メンバーのリソースからすると巨大といっても良いかもしれません。
このGEES、おしゃれな言い方をするとマイクロサービスの集合体であり、サービス毎に担当者が分かれていますがDBに格納されるマスターデータ等共通リソースも多々あったりします。
このような場合はシステムのセキュリティを担保するため、全システムに影響を与えるようなクリティカルな作業を担当するメンバを限定する必要が発生したりします。
ただ、これをするとそのメンバは神様になってしまいますので、権限が集中してしまい色々と不都合がでてきます。*5
で、Newsにおいては以下理由をもって神様を無くしました。
- 神様を作るとその人に作業が集中してしまう
- 神様、自分を守れない問題*6
- インフラ担当は必然的に神様になる → 勘弁してください
- 人数すくなすぎて、バランスの良い施策がとれない
大丈夫か？ と思いましたか？
大丈夫です！
解決しよう
リソース不足
- 全部コード化しよう
- インフラだけでなく、開発やR&Dも必要ならばインフラのコードを書こう
- みんなでレビューしよう
- なんなら、Terraform apply/destroy もみんなできちゃえばいい
- EC2の利用は最低限にしよう*7
お、なんか良さげですね。
一人でインフラを作らなくてすみそうです。
レビューもしてもらえます。
開発はインフラ担当の作業完了を待たなくてよさそうです。
解禁にも間に合いそうです。
それに、インフラはアプリケーションのコードを書かないので一番楽です。*8
実際にやったこと
セキュリティ施策
こんなポリシーです
- 前提としてお客様から預かってるデータを持っているシステムでは無い
- ↑とは言えデータベースの監査はガチガチ
- メンバ全員、AWSに対しても、そこで稼働してるシステムに対してもできることは同じ
- AWSのAPIキーは全員出せない*14
- ↑があるのでインフラの変更は専用のインスタンスから行う
- 操作ログは収集されており全員閲覧可能だが編集はできない*15
- サーバにログインするときは申請・承認を行う*16
- サーバログインIDの一元管理*17
こうすることで、全員がお互いの作業を監視している状態をつくっていますし、なにかあったときの追跡が可能になっています。
なお、監視という言葉は悪いですがギスギスはしてないです。
大事なこと
メンバの理解が一番大事
いきなり泥臭いです。
ただ、これはNewsに限った話ではなく、どんなガチガチのセキュリティ施策を打ってるシステムでも同じで理解してもらうのが一番大事だと思います。
今回の施策については、なんでこういうセキュリティポリシーなんだっけ？ なんで開発がTerraform書くんだっけ？ となってしまうと恐らく不満が先行します。
特にセキュリティポリシーについては丁寧な説明が必要で、例えばなんでもできるサーバは何してもいいんだと勘違いする人がいるかもしれませんので権利と責任はセットであることを説明しています。
現時点では人数も少なく相互に理解しあえる体制のため破綻してませんがメンバが追加された時などは丁寧な対応が必要で実際にそのようにしてますし、体制や規模の変化や伝えるのが難しくなる他の要因が発生した際は見直す必要はあると思っており、いつまでもこの施策ではない可能性があるということも含めて理解をしてもらう必要があると思います。
実際にどうだったか
いい話
開発もスムーズに進みましたし、開発の責任者からはやりやすかったというコメントももらえました。
実はNews以外にも並行で新規の開発案件を担当してたのですが、どちらも滞りなく進められるくらい僕にも余裕がありました。
釣りも去年と同じくらいは行けました。
反省点
Terraformのレビューはインフラエンジニアは必ず見なければならなかったので少しだけボトルネックは残りました。
構築及びセキュリティポリシーは開発開始当初は少し違いました。
開発中に色々と不都合が出てきて都度最適解を探しながら進めた為、インフラの構成変更を2日程度行えない期間を2回つくってしまいました。
最後に
開発エンジニアからみて、インフラエンジニアがボトルネックになる気配がしそうなとき、インフラエンジニアの方が辛い未来が見えた時に参考にしてもらえると幸いです。
*1:DSOCはSansanにおけるデータ統括部門です。
*2:ただ、てんとう虫コミックス版ドラえもんの6巻の最後,7巻の最初,25巻の最後のエピソードはコマ割,セリフほぼ覚えてるんです。不思議です。ドラえもんとのび太が眠らなくてもつかれない薬をのんで、街にでるコマとか最高ですね。つか、この薬は大丈夫なんでしょうか。なお、25巻にもヘソリンスタンドっていう様子がおかしい道具がでてきます。
*4:News配信システムの内容について深くは踏み込みません、それについては他の人が書いてくれる事を期待してます。
*5:任意アクセス制御におけるroot権限強すぎ問題みたいなものですね。GEESではここらへんをうまい具合にバランスをとってます
*6:なにかあった時、まっさきに疑われる。
*7:ECSやlambdaを使ってサービスは提供されてます
*8:嘘です。インフラだけで完結して且つ神様作業では無い作業はたくさんあります。
*9:Redash,Sentry,Metadataを使ってます。RedashとMetadataは用途が被ってますが、Metadataは評価中です。今の所、Redashが結局一番使い慣れてる&Athenaに対応してるのでRedashの方が良いかもと思っています。
*10:Terraformを実行するサーバのAD参加部分のみAnsibleを使おうかなと思いましたが、対象は1台だけだしコマンド一発なのでという気分でやめてます
*11:昨今、インフラがー！はあまり意味がなく、結局サービスが動いている方が重要なのでサービス視点で監視をするポリシーです。それをインフラ担当が設計するのは？な部分があり主担当である開発グループにお願いしてます。ここらへんはケース・バイ・ケースだと思います
*12:destroyする際、消されては困るものや消す必要が無いもの。例えばNewsではCogniteを使ってますがユーザプールを削除されると非常にめんどくさいとかがあります
*13:インフラも楽でうれしい
*14:rootアカウントは厳重管理されてます
*15:一部、現在も構築中です
*16:DSOC全体の申請・承認システムを利用しています
*17:これはNewsシステム外で動いています
