あけましておめでとうございます。Open Policy Agent(以下OPA)/Rego x 監査で継続的監査をあたりまえにしていきたいと思っているMoney Forward Kessai（以下MFK）のshinofaraです。 Regoとは、OPAのポリシーを記述する言語です。

本日はOPA / Rego Advent Calendar 2021の影響を受けて、MFKでOPA/Regoを活用して実現している監査に関することの1つを紹介できればと思いブログを書き始めました。

そもそもOPAって何？に関しては、以下のZennに詳しく書かれておりますので、こちらのブログでは割愛させていただきます。 OPA/Rego入門: OPA/Regoとはなんなのか

こんにちは、マネーフォワードケッサイ（以下MFK）SREチームのshinofaraです。今回は権限の仕組みを見直した話と、それを実現する為に開発したgranterというツールについてお話したいと思います。 また今回granterのcore部分をmfkessai/granter_coreとして公開しています。

久しぶりの登場となりましたマネーフォワードケッサイ（以降MFK）CTOの篠原です。

事業が成長し続ける事で、情報管理、GCPリソース等のアクセス権限や、そしてオペレーションやセキュリティ観点でのリスクコントロールなどを意識する場面が増えてきます。 今回、MFKとして正しいと思う形で正しく運用できているかを保証する為に導入していた仕組みなどを、0から再設計しなおしたお話ができればと思います。

まず今回のテーマである正しいとは何かを書き出したいと思います。

• GCPリソースに対するメンバーの権限は必要最低限に留める事
• 本番環境にデプロイされるソースコードが社内で定める条件を満たしている事
• 社内ツールで読み書き可能なメンバーが必要最低限である事
• またそれぞれで意図通り運用されたことを保証できる事

一部ではありますが開発組織によって定義される正しさは異なると思いますので、ここではMFKの考える 正しさ に基づいていることをご理解いただけると嬉しいです。

まず何をやめたのか

1. SREに本番に関する権限が集中することと、SREへの依頼が必要になる事
2. 社内アプリケーションそれぞれでのACL管理
3. Githubリポジトリ作成のIaC管理、もしくはチケットでの作成依頼

ここからは、これらをやめるために何をしたかをお話していければと思います。

きづけば2021年ですね。12月末に書いたこの記事は年末休暇の関係で、公開がこのタイミングになりました。あけましておめでとうございます。 今回は、マネーフォワードケッサイが利用しているGCP/GKEのIngreeまわりを振り返ってみたいとおもいます。

創業初期

2017年3月時点ではGCPには証明書を自動的に作成する仕組みがなかった事もありますが、まだまだ証明証は信用の為にEVを買うという考えが強かったので、EV証明書とワイルドカード証明書を購入してIngressに設定してました。

2020年11月2日にMF KESSAI株式会社からマネーフォワードケッサイ株式会社へ名称変更を行いました。またサービスブランドも合わせて変更しました。 https://corp.mfkessai.co.jp/press/2020/11/02/

サービスブランドの変更に合わせてサービスサイトをノーコードでリニューアルを行いました。