はじめに
この記事はBASE Advent Calendar 2021の3日目の記事です。 devblog.thebase.in
BASE Corporate Engineering CSEグループ マネージャーの小林 (@sharakova) です。
タイトルに記載のとおり、BASEにおけるIT全般統制とCSEグループが取り組んだ内容を説明させていただきます。
BASE株式会社は、2019年10月25日に東証マザーズに上場しましたが、上場企業は、金融商品取引法（いわゆるJ-SOX法）の遵守が求められます。そのため、2021年度末までにIT統制として不十分な項目の是正・必要書類の作成などが必要となってきます。
私は、バックエンドのアプリケーションエンジニアとしてBASEに入社をして、2020年にコーポレートエンジニアのチームに異動しました。コーポレートエンジニアが取り組むべき内容なども分からないまま異動し、J-SOXの対応としてIT統制が必要だということ、さらに期限があり大変なプロジェクトだということは、異動してから知ることになります。
昨年のアドベントカレンダー記事で、CSEグループがIT統制の整備に取り組んでいる事を書かせていただきましたが、この1年で取り組んできたIT統制、主にIT全般統制（ITGC）の取り組み・整備についての概要を説明させていただきます。
社内説明会
CSE・情シス内での輪読会（2020年）
CSEメンバーには、IT統制や内部統制について深く理解しているメンバーがいなかったため、プロジェクトを開始する前にメンバー全員でIT統制についての輪読会を実施しました。
金融商品取引法（いわゆるJ-SOX法）は2006年に成立し、2008年に適用が開始されました。上場企業においてはJ-SOX法に遵守するために、IT統制が必要になります。
ただ、2008年以降のIT業界の変化は激しく、2020年代においてアジャイル開発、GitHub、AWSの利用も主流となり、これらの技術やSaaSなどを利用しながら、どのような方法ならJ-SOXに遵守できるのか、メンバー同士で議論することになります。
エンジニア向け説明会の実施（2021年3月）
2020年末までの課題として、売上に関わるような開発が突発的にされており、IT統制として知るべき変更内容が共有されていない状況が続いていました。
是正するため、2021年最初に取り組んだのが、バックエンドエンジニア向けに社内説明会を実施することにしました。
CSEグループが取り組んでいる内容を共有しつつ、IT統制の必要性、考え方を説明。それに伴い開発ルールも変更されることを伝えました。ほぼ全てのバックエンドエンジニアやPMの日々の業務に関わるため、協力・理解してもらう必要があります。
説明会を実施後にも、多くの機能が開発・リリースされておりますが、売上に関わるような開発は、最初にCSEグループに相談してもらえるようになり、社内にIT統制の考え方が浸透するきっかけになったと思います。
IT全般統制
IT統制の中で、基本となるのがIT全般統制（ITGC）になります。
IT全般統制で売上を管理しているシステムを特に重要視する必要があり、特に以下の項目においては、操作ミスや不正などを防止（予防的統制）・発見（発見的統制）の２つの観点から仕組み・ルールを整備してきました。
- BASE管理画面
- GitHub
- データベース
- サーバーログイン・設定変更
- 会計ソフト
- 決済代行会社アカウント
以降、詳しく説明します。
BASE管理画面
BASE管理画面は、BASEの社員などが利用する社内用の管理画面の事で、購入を強制的にキャンセル、売上データの変更、割引率の設定、クーポンの発行などサービスを運営する上で必要な機能ではあるが、売上に関わるような重要な操作も可能で、さまざまな仕組みやルールを整備しました。
ロール / Access Control List (ACL)
BASE管理画面では、利用者全員に管理者、経理、閲覧者、外部委託者などのいずれかのロールを設定する事で、操作可能な機能を制限しています。その上で、特に気をつける必要があるのが、管理者、経理ロールとなります。
管理者ロールは、アカウント作成・他のロール設定変更を含めて全ての機能が利用可能です。
経理ロールは、売上データを操作などの売上に直接関わる操作を可能としています。
権限の付与ルールの整備などを行いながら、アカウント台帳の作成とロール権限の再定義などをしました。これにより、想定外の人への誤ったロールを設定するなどのミスをなくし、売上に関わる操作でも、申請者と承認者を適切に分離する事で、誤った操作を防ぐ設計に変更しています。
操作ログの通知
上記のロールの設定をすることで予防的統制を実施し、発見的統制として重要な操作のSlack通知機能を実装し活用しています。特にロールに関する変更操作など、影響範囲が大きく、気づいたら「売上に関わる操作が誰でもできる状態」などならないように、監視する体制づくりも実施しました。
GitHub
BASEのOrganizationでは、リポジトリが350以上存在していますが、すべてのリポジトリをIT全般統制の対象とする必要がなく、まず重要なリポジトリを精査し統制対象と定義しました。対象リポジトリにおいてコードレビューを必須化、変更理由の記載などより強いルールに変更することにしました。
対象リポジトリ
- BASEサービスの基本となるリポジトリ
- 売上を編集・操作できるリポジトリ
- インフラの設定変更が可能なリポジトリ
- 共通ライブラリなどのリポジトリ
いままでのBASEでは、障害時などの緊急のコード編集が必要になることが考慮されているなどの理由から、コードレビューを厳格化できておりませんでした。この数年でエンジニアの採用も進み、またコロナ禍において、テレワークが定着化し、緊急時でも複数人で対応できる体制になったおかげもあり、Pull Request のレビューを厳格することができ、対象リポジトリにおいてレビューされてないコードがデプロイされる事はなくなりました。
データベース
近年ではデータベースと一括りにできない部分ではありますが、BASEでは、Amazon Auroraをメインのデータベースとして利用しています。
このデータベースのデータの健全性を守る事が最重要の項目であり、データベースの値に間違いが無いことを証明するため、上記のBASE管理画面、GitHubなどあらゆる手段で守っていると言っていいでしょう。
しかし、現実的にはSQLを流して、データを書き換えるなどの業務も発生します。
SQLでの更新検知
SQLを手動で実行してデータ更新については、他のエンジニアのレビューしてから実行するルールが確立されていました。さらにレビューした内容でのSQLを実行したのか、不正なSQLが実行されていないかを検知することをすることにしました。
まずは、”BASEシステムが利用するDBユーザー”と、”SQLでの書き換えできる人のDBユーザー"を完全に分離し担保する必要があり、その上で、手動でデータベースを更新をした場合に、Slack通知する事を構築しています。
バックアップデータからのリストア試験
データベースを復旧試験・手順書の見直しました。実際にはデータベースだけではなく、サービス提供全体の復旧試験などを行った方がよいです。しかし、実際の復旧構築の試験となると、他のSaaSとのつなぎ込み部分など多岐にわたるため、今年度は試験を範囲を限定し、毎年復旧試験の内容を変えて実行するなどを考えていきたいと思っています。
サーバーログイン・設定変更
アカウント管理
誰がサーバーにログインできる状態なのか、台帳管理などを用いて証明する必要がでてきます。BASEではChefを利用したサーバー構築、設定変更を行っているため、Chefを管理しているGitHubリポジトリへのアカウント追加のPull Requestが申請・承認となり、コード化された設定ファイルが証跡（台帳）となるように、監査法人へ説明しています。
臨時ジョブ（バッチ）の実行
通常のジョブ実行にはcrontabを利用したジョブ実行を行なっていますが、臨時的にジョブなどを実行したりする場合などがあります。そのため、社内でバッチサーバーと呼ばれるサーバーに、SSHログインし、手動でジョブを実行できる環境などが整備されております。
しかし、ログインできるアカウントを管理しているとはいえ、誰がどのような作業をしたのか把握できている状態とはいえず、どのサーバーでどんな作業をするのか、申請・承認を経て実行していただくように仕組み・ルールを変更を行いました。
ソースファイルの改ざん検知
GitHubでコードレビューを厳格化しても、サーバーにログインできると、ソースファイルをサーバー上で書き換えが可能な状態となります。SSHログインできるアカウントを管理しているとはいえ、リスクを伴います。
Dockerなどでサーバーを構築できれば、そもそもSSHログインできないなど、ソースファイルをそもそも書き換えできない状態にするのが望ましいとは思いますが、すでに確立しているデプロイシステムなどもあり、既存のEC2サーバーにファイル改ざん検知する仕組みを導入し、Slack通知で検知する仕組みを構築することにしました。
会計システム
BASEでは、会社設立当初から会計システムとして外部のパッケージソフトウェアを導入し利用しています。
BASEシステムと同様に、売上を管理する重要なシステムでありながら、社内のエンジニアは運用方法を把握できておらず、IT統制の内容確認には苦労しました。
BASE社内で開発している製品ではないものの、ベンダーとの契約内容の確認・アカウント発行ルール・ロール設定・バックアップ・復旧手順の作成など、整備する項目はあります。
バックアップ/リスト手順
利用している製品のバージョンも関係しているのですが、日次の自動バックアップなどを設定できなく、経理部門が手動でバックアップしている状態でした。
ただ、ヒヤリングしてみると同じサーバー内にバックアップをとっている事が発覚し、障害が起きた場合に、結局復旧できそうもない状況であることがわかり、サーバーからGoogle Driveをマウントする形に設定変更をし、バックアップ先の変更をしました。
システムを外部ベンダーに依頼だけで、BASEのエンジニアが積極的に運用に参加していなかったなどの課題も発見しました。
決済代行会社アカウント
BASEでは、クレジットカード、コンビニ払い、Amazon Pay、PayPalなどの多様な決済方法を提供しており、各決済代行会社を通じて決済させていただいています。購入時などは各社のAPIなどを利用することで決済をし、BASEのデータベースと決済代行会社の決済のデータが常に同期されている事を担保しています。
しかし、各決済代行会社の管理画面がそれぞれ存在しており、管理画面にログインを行うと、決済にまつわるさまざまな操作が直接可能になります。
権限によっては、決済を強制的にキャンセルなども行えるため、決済代行会社のアカウントは厳重に管理する必要があり、アカウント発行のルールの作成と、申請・承認・発行フローの整備を行いました。
終わりに
すごく厳格なルールを整備してしまうと、私がBASE社に入社して最初に感じたスピード感が失われてしまう可能性もあります。スピード感を保ちながら、それでいて安全にするために、何ができるのかという観点でメンバーとも議論を重ねながら、さまざまな事に取り組んでまいりました。
1年を通じて、ルールを作成するたびにエンジニアへの説明会を繰り替えしながら、時にはエンジニアからの反発などもありましたが、一度作ったルールをそのままにするのではなく、継続的にルールを見直していく事が成長をするBASEらしさだと思うので、変化できるように体制強化を目指していきたいです。
またYouTubeの方で、”Web系ベンチャー上場後の「現場のDX」の難しさ”という内容でインタビュー動画を上げさせていただいているので、合わせて見ていただければと思います。
明日は、フロントエンドエンジニアのがっちゃんの「Denoの今を知る」の記事を公開する予定です。お楽しみに。
