SOC2までの道のり - Cybozu Inside Out | サイボウズエンジニアのブログ

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。

こんにちは、kintone開発組織でエンジニアリングマネージャーをしている上岡（@ueokande）です。少し前の話ですが、グローバル市場向けkintone¹（以下kintone.com）において、2023年12月にSOC2 Type 1、2024年8月にSOC2 Type2の保証報告書を受領しました。以降も毎年報告書の更新をするために、継続的な評価および運用改善に取り組んでいます。

サイボウズはこれまで、ISMSやISMAPなどのセキュリティ認証や評価を取得してきました。しかし、グローバル市場ではSOC2の認知度が圧倒的に高く、kintone.comのグローバル展開において重要な役割を果たします。

SOCはより厳格なセキュリティ基準が求められ、取得までおよそ2年もの期間を要しました。この記事では、kintone.comがSOC2保証報告書を受領するまでの取り組みを紹介します。

SOC2について

SOC2はAICPAが定めたサイバーセキュリティのフレームワークです。セキュリティ、プライバシー、可用性、機密性、処理の完全性の5つの項目でデータセキュリティの基準を定めています。 SOC2は第三者監査法人が企業を評価して報告書をまとめるもので、これらの5つの項目に準拠するようルールを制定し、実際の運用を行う必要があります。

SOC2には監査期間の違いによってType 1とType 2があります。Type 1は特定の日付時点での監査、Type 2は6ヶ月以上の期間にわたる監査を受けます。長期的な運用状況が評価されるType 2は、Type 1と比べてより厳格な監査が求められます。

具体的な取り組み

SOC2ではISMSよりも厳格な基準が求められます。 SOC2の監査では以下のポイントで確認されました。

セキュリティルールが十分な水準か。
セキュリティルールに従ってきちんとプロセス化されているか。
プロセスがきちんと実施されているか。

1.および2.については、社内のセキュリティルールや運用プロセスのドキュメントを監査法人に提出し、フィードバックを基に改善しました。 3.については証跡（エビデンス）を記録・提出することで、プロセスに沿った運用ができているか確認されます。Type 2では監査期間中の無作為抽出による証跡の提出が必要となります。そのため、プロセスの徹底と自動化により証跡の記録漏れ防止に気をつける必要がありました。

以下ではkintone.comにおける具体的な取り組みをいくつか紹介します。

本番環境の定期チェック

kintone.comはAWS上で運用しており、AWS GuardDutyによるアクティビティ監視、AWS Trusted Advisorによるクラウド最適化、AWS Bulletinによる脆弱性の確認をしています。 SOC2監査より前から日次でチェックしていましたが、これを証跡として出せる形に業務を整理しました。

その記録先としてkintoneアプリを作成し、日次でチェックの記録を残し、監査時に証跡として提出できるようにしました。

第三者チェックのルール化

SOC2監査では、開発業務が個人の判断ではなく第三者チェックのもとで実施されているかが求められました。もちろん従来から、コードレビューやQAエンジニアによるチェックを実施していました。 SOC2監査に向けてこれらの運用をルール化し、証跡を残せる形に整備しました。そのためにルールとして改めて整備した点をいくつか紹介します。

機能開発が適切なプロセスで承認を得ているか。
- プロダクトマネージャーによる成果物の確認
- 他の開発者によるコードレビュー
- QAエンジニアによる機能試験と試験結果の添付
- 経営陣によるkintone開発計画の承認
インフラの変更が適切なプロセスで承認を得ているか。
- 他の開発者によるPull Requestのコードレビュー
- 他の開発者による手動オペレーションの手順レビュー

これらのルールを厳守できるように、レポジトリのブランチ保護ルールの見直し、プロダクトバックログアイテムの管理の整備、オペレーション記録の整備をしました。

以下は現在のオペレーション管理アプリの状態遷移図（kintoneアプリのプロセス管理機能）です。

本番環境アカウントの付与ルールと棚卸し

kintone.comの本番環境へのアクセスは限られた一部社員のみに許可しています。本番環境へのアクセス権限の付与は開発チーム側で判断し、異動や退職時に都度アカウントを削除していました。SOC2監査に向けて、アカウント付与ルールの明確化と、新たに月次の棚卸しプロセスを整備しました。

アカウント付与に関しては社内でISMS従事者の管理ルールがあり、それに基づくアプリが運用されていました。それを元に開発チーム内でアカウント付与基準を定義しました。棚卸しでは、アプリの登録内容と実際の権限があるユーザーを突合し、不要なアカウントを定期的にチェックしています。

この作業をツール化して、月次で照合内容と作業内容を記録することにしました。

アジャイル開発の妥当性の説明

kintone開発組織の多くのチームはスクラム開発を導入しています。スプリントレビューでは開発成果物をデモで確認していますが、その内容を証跡として残せないという課題がありました。また一部のチームではモブプログラミングを採用しており、変更点のチェックとレビューを口頭で済ませることができます。こちらも確認結果を証跡として残せないという課題がありました。この課題を解決するために、GitHubのBranch Protection設定とIssueテンプレートを導入し、確認記録を残しました。

以下は基盤の運用チームのGitHub Issueの抜粋です。スクラムイベントでチェックボックスを埋めて、タスクが問題なく完了したか確認しています。

おわりに

セキュリティ監査と開発スピードの両立は常に課題となります。開発スピードを犠牲にしないセキュリティルール・プロセスの整備は常に頭を悩ませます。運用上の（退屈な）業務を減らすために、アカウント棚卸しのように自動化した部分もあります。毎年SOC2の報告書を更新するために、継続的な評価および運用改善に取り組んでいます。

しかし、SOC2に対応し、より強固な運用を実現するために、大事な過程であったことは間違いありません。短期的には開発速度を低下させる可能性もありますが、今後成長するkintone開発組織にとっては長期的なメリットを期待しています。

SOC2監査にあたり、担当いただいた監査法人の皆さまから、多数の証跡の確認やフィードバックをはじめ、さまざまなご助言をいただき、おかげさまで保証報告書を無事に完成させることができました。ここに改めて感謝申し上げます。