クラウド会計ソフトfreeeのデータセキュリティと内部統制

Transcript

1. freee 株式会社 クラウド会計ソフト freeeの データセキュリティと内部統制 2018.12.06
2. 大学在学中にIPストリーミング技術の会社を立ち上げ、 技術責任者を担当。 その後、防衛省・自衛隊に入隊。 陸上自衛隊で野外ネットワーク部隊を担当した後、 システム監査人として、各システムのシステム監査・セキュ リティ監査、脆弱性診断を担う。 現在は、freee のセキュリティ専門チームであるCSIRTで、内 部統制、セキュリティマネジメント等を担当中。 一番嫌いな攻撃は、MITMA（中間者攻撃）。 Takanori Awatsu 粟津 昂規 freee株式会社 セキュリティマネージャー 2
3. Overview 3 　03　将来に向けての取り組み 　02　freeeでのデータセキュリティとデータ活用の一例 　01　freee株式会社と クラウド会計ソフトfreee 紹介
4. 01 freee株式会社と クラウド会計ソフトfreeeの紹介 4 Section
5. Company Profile 会社名 freee株式会社 設立年月日 2012年7月9日 代表取締役 佐々木 大輔 資本金 161億603万円（資本準備金など含む） 従業員数 465名（2018年7月末時点） 事業内容 クラウド型バックオフィスサービスの 開発・販売
6. 6 6 PRODUCTS
7. 会計・給与共に法人シェアNo.1 7 クラウド給与ソフト 市場 40% クラウド会計ソフト 市場 35.2% 100万 事業所 以上 10万 事業所 以上 * BCN調べ * MM総研調べ * 2017年8月より、クラウド給与計算ソフト freeeは、機能を強化し、新たに 「人事労務 freee」というサービス名に変更しました。 　
8. 8 　 　 アイデアやパッションやスキルがあればだれでも、 ビジネスを強くスマートに育てられるプラットフォーム スモールビジネスを、世界の主役に。
9. 9 スモールビジネスと大企業の差は2倍以上 1,327万円/人 558万円/人 クラウド化も進まず、IT投資の原資も乏しい中小企業… 大企業との差は開くばかり 出典：2018年版 中小企業白書 ※大企業とは資本金10億円以上、中小企業とは資本金1億円未満の企業 大企業 付加価値額 中小企業 付加価値額
10. 10 中小企業のクラウド化には大きな余地 中小企業におけるクラウドサービス普及率は大企業と比べ大きな差がある 40% 72% 中小企業 クラウド普及率 大企業 クラウド普及率 出典: 平成28年度 通信利用動向調査 ※大企業とは資本金10億円以上、中小企業とは資本金1億円未満の企業
11. 11 業務をシンプルにする4つの解決ポイント 収集 確認 記帳 電子取込 解決 1 自動仕訳 解決 2 クラウドコラボ 解決 3 会計・申告連動 解決 4 決算・申告 1010101010101101000101001010001101010011 0100100101010010101011001001001101010111 1000110101000101010100101010110010100101 0001010111100101010100100101101010101100 1010100101001010001111010101010101010100 0110110110111001010001010101001010101101 1011010010010100110101010010010101011010 1001000101010010101010001011001010101100 1001010111010101001001010010100101010101 1001000101010010101010001011010101010100
12. 12 　 会計業界の活性化を促進 会計事務所様 の日常業務 効率向上 作業時間 顧客に 向き合う時間 一人あたりの 付加価値アップ 給与アップ
13. クラウド会計ソフト freee
14. 14 　 いつでもどこでも推測された仕訳をチェック
15. 最新テクノロジーでリアルタイムデータ収集 15 クレジット 金融機関 決済サービス 業務データ freee Core Engine
16. 16 16 金融機関・ 各種サービス連携数 3,822 POSレジ 金融機関 ログイン・ 認証 業務システム ECサイト 共有ツール 決済サービス ファイル取込 クラウド会計ソフト 業界最多の連携数を実現
17. 17 抱えている顧客情報 IBへの 認証情報 取引データ 明細データ 個人情報 決算情報 業務データ これら全てを、①漏れなく守っていき、②より優れたプロダクトへ反映できるようにすること が、freeeにとって求められるデータセキュリティのひとつ。 多くの重要情報をお客様からお預かりしている
18. 18 求められている社会的責任 金融機関とのAPI接続 金融機関とのAPI接続により、明細取得、振込等が可能 電子決済等代行業者 銀行法 第52条に基づく「電子決済等代行業者」の国内第１号。 明細取得API連携 振込API連携 金融庁ホームページより
19. freeeでのデータセキュリティとデータ 活用の一例 02 Section 19
20. 20 直面しているセキュリティリスク 会計ソフトとしての完全性・可用性の確保 • データもプログラムも、改ざんさせない • ダウンさせない、失敗や不具合をすぐにロールバックできる 外部脅威からの防護 • サイバー攻撃の検知と切れ目のない防護 • 攻撃の試みを未然に防ぐ 内部不正の抑止と内部過失の防止 • リモートワーク、様々なプラットフォームといった多彩な環境 • 複雑化し、巨大化するプロダクトと事業
21. 21 要求される内部統制とリスクアセスメント 開発生産性を落とさない統制 • 競争力としての開発力と、その生産性を落とさない • ガチガチのセキュリティであればいい、というわけにはならない • 以下に開発や運用の流れに、低負荷でセキュリティを組み込むか サービスの進化、事業速度についていくリスクアセスメント • 毎日デプロイされるサービス、進んでいく事業 • どんなリスクがあるかを素早くSyncし、カバーしていく • 多少マッチョであっても問題があれば対策し、あとから改善してスマート化 ・ITベンチャーゆえの競争力維持のため、ただ管理を強化すればいいわけではない ・コスト以上に難しい課題感
22. 22 各フェーズでの取り組み 運用 開発 分析 IBへの 認証情報 取引データ 明細データ 個人情報 決算情報 業務データ
23. 23 3段階の環境（顧客情報と開発リスク） プロダクトのステージ ・内部過失（ミス）、内部不正（不正プログラム混入） 　等のリスク 　→内部統制（予防/発見）＋Test,Review&Approve 会計freee [Production] （本番環境） 会計freee [Staging] （動作確認環境） 会計freee [Development] （開発環境） ・外部脅威（サイバー 　攻撃等）のリスク →WAF/IPS&監視 ・GitHub 　レビュー ・自動テスト ・E2Eテスト ・動作確認 ・本番適用 　手順準備 ・リスクにあわせて環境を準備し、異なる対策を実施して顧客情報を守る
24. 24 各フェーズでの取り組み 運用 開発 分析 IBへの 認証情報 取引データ 明細データ 個人情報 決算情報 業務データ
25. 25 SaaS開発の特徴 • １日数回のデプロイ ◦ デプロイ = 本番環境へのプログラム適用・アップデート ◦ 開発→単体テスト→E2Eテスト→動作確認→本番適用の流れ • 大量の仮想マシンと開発者 ◦ AWS上に存在する多数のEC2インスタンス ◦ 100名以上の開発者 プロダクト開発 ・隅々まで細かい統制をデザインすると、デプロイがまわらない ・とはいえ、開発者の適切な権限管理とデータアクセス管理は必要不可欠
26. 26 ①freeeでの開発統制の基本 • GitHub Workflowを中心としたTest,Review&Approveが基本 ◦ GitHubのベストプラクティスにちゃんとのせる ◦ Reviewは必須 • ＋JIRA, Issuesなどの「開発根拠」紐づけのMust化 ◦ 開発理由がちゃんと分かるし、レビューされている ◦ 単独開発、レビュー漏れをふせぐ プロダクト開発 ・品質を保つ＆不正プログラムを仕込ませないため、単独開発は”させない＆できない” ・Webhookやテンプレートを活用した自動化
27. 27 ②AWSとSAMLの利用 • IDaaSと連携させる ◦ コンソールへはIAMユーザとしてログイン • AWSのAceessKey, Secretをローカルに置きたくない ◦ クレデンシャルの漏えいリスクを下げたい ◦ AWS CLIを使うときに、シークレットを保存せずにすむ ◦ 開発ユーザが覚えるのはIDaaSのパスワードだけですむ プロダクト開発 ・SAML連携で、大量の開発者をIAMユーザ＋IAMロールで管理 ・リスクを下げつつ、かつ開発者の生産性を阻害しない SAML Assertion
28. 28 各フェーズでの取り組み 運用 開発 分析 IBへの 認証情報 取引データ 明細データ 個人情報 決算情報 業務データ
29. 29 会計freeeを守れ • 高まるセキュリティ脅威 ◦ Webサービスとして、当然サイバーセキュリティは日々考えること ▪ 攻撃を受けた経験をもとに、強化していく ◦ しかし、脅威は外側だけではない • 内部不正・内部過失を防ぐ ◦ 人間である以上、ミスをする ◦ ミスができない環境、誰もが見える環境をつくりこむ ▪ ＝標的型攻撃対策にも有効な対策に プロダクト運用 ・外部脅威だけでなく内部脅威も含んで、freeeを守っていく ・開発、運用上のクリティカルなものを抑止防止できる機構をつくりこむ
30. 30 ①各サーバへのSSHログイン • 専用の踏み台サーバを準備 ◦ SSHの入り口・認証を一箇所に絞る ◦ ひとつのアカウント、公開鍵でどのサーバへも入れる ▪ 共有アカウントを作らない、不要な鍵共有をしない • ロールベースのアクセス制御 ◦ 各サーバに入れるアカウントの組み合わせをロール単位で制御 ◦ ユーザアカウント一覧とロール一覧は、GitHub上でソースコード管理 ▪ 全ての変更にReview & Approveを導入できる ▪ 監査対応も容易 • 2要素認証の追加 ◦ 公開鍵認証＋OTP2要素認証を追加し、さらにセキュアに プロダクト運用
31. 31 ロールベース制御のStepサーバ プロダクト運用 Stepサーバ （SSH接続先を アクセス制御） • 入り口となるSSH踏み台サーバ（通称Step） ◦ 開発範囲・役職に応じたSSHアクセス権限を一括制御 ◦ GitHub上でレビューから付与・削除まで管理できる 各EC2(仮想マシン) SSH GitHub上で権限と アカウントを管理 2要素認証が必須
32. 32 ②本番環境での作業監視その１ • SSHした後のリスク ◦ 作業ミス or 不正作業をどう抑止するか？ ◦ なるべく見えるようにする＋記録する、を基本 • SSHログインの通知 ◦ ログインすれば、すぐにSlackに通知 ◦ 本番環境に入るときは、作業内容を宣言 プロダクト運用
33. 33 SSHログイン→Slack通知 プロダクト運用 Stepサーバ （SSH接続先を アクセス制御） 各EC2(仮想マシン) SSH リアルタイムでログイン状況を通知（誰でも閲覧可） 互いに作業内容を宣言＆確認
34. 34 ②本番環境での作業監視その2 • 作業内容の全記録 ◦ コマンドだけでなく、ttyの全てを記録 • 本番環境でのDB書き込み・コピー作業の統制と監視 ◦ 本番DBへの書き込み権限取得は、本部長承認が絶対に必要 ▪ 承認ワークフローは、社内の別システムでチケット化 ◦ DB書き込み権限取得は、リアルタイム監視 ▪ 本部長承認のチケットがなければ、即CSIRTがヒアリング ◦ scp、rsyncといったコマンドもリアルタイム通知＆チェック プロダクト運用
35. 35 全てを記録する プロダクト運用 Stepサーバ （SSH接続先を アクセス制御） 各EC2(仮想マシン) SSH • コマンド履歴だけでなく、コンソール出力も保存 ◦ lsコマンドなど開発者が見えたもの全てを記録 ◦ PC上のスクリーンショット、スマホ撮影からのデータ漏えいを確認で きるようにしている ※画面はイメージです コンソール入出力を全て記録
36. 36 DB書き込み プロダクト運用 社内freeeシステム （申請承認ワークフロー） 本部長申請 Stepサーバ 承認済みのチケットURL 本番環境コンソール SSH SSH 接続 承認済みのチケットURL ・本番DBへの書き込みは厳重に保護 ・書き込み可能状態になる際には、本部長承認のチケットが必須 顧客情報データベース
37. 37 監視とモニタリング監査 プロダクト運用 Stepサーバ 本番環境コンソール SSH SSH 接続 ・書き込み権限の取得は、セキュリティチームが妥当性を調査 ・継続的なモニタリング監視を実施している 承認済みのチケットURL
38. 38 ③SercurityGroupのコードベース管理 • Security Groupとは ◦ AWS上のEC2などへのIP/ポートアクセスを制御するもの ◦ AWS上のFirewallのひとつ • SGの変更と監視 ◦ 変更発生時は、全て差分チェック ▪ 毎日差分の内容が配信される ▪ Jenkinsで処理 ◦ 変更そのものもGitHub管理へ移行中 ▪ Terraformの利用と統合 ▪ Review&Approveがよりスムーズに プロダクト運用
39. 39 SecurityGroupのコードベース管理 プロダクト運用 変更内容をPR 自動連携 自動適用 インフラチームが Review&Approve 適用結果を確認し マージ ・TerraformとCIの活用により、承認と変更履歴は全てGitHub上のコードに残る ・設定変更が乱立せず、整然と管理できる
40. 40 ④IPS、WAFと監視 • サイバー脅威から守るために ◦ EC2インスタンスには、全てTrendMicro DeepSecurityを適用 ◦ AWS WAFも配置 • 適用とチューニング ◦ 負荷上昇に伴うオートスケーリング時に、EC2のインスタンスに DeepSecurityを自動適用 ◦ シグネチャのチューニングがキモ （最初はアラートだけ、徐々に絞っていく） • 監視と通知 ◦ Guard DutyとSlackの活用 プロダクト運用
41. 41 運用工夫の一例 • オートスケーリング時の工夫 ◦ 頻繁にインスタンス数が増減するfreeeの全てのインスタンスに DeepSecurityを適用 プロダクト運用 予めリソースを チェック 本番インスタンス(増加分) 負荷増加時に展開 ビルドキャッシュとし て予め保存 チェック済みのリソースは、 セキュリティチェックをパス ・予めチェック済みのfreeeプロダクトビルドをS3に保存 ・インスタンス増加時に、チェック済みリソースを展開することで、速度/負荷を低減
42. 42 ⑤Hardening Program • サイバー脅威を知る ◦ サイバー脅威を知るには、攻撃者の思考を知るのが一番 • 脆弱性を探せ！ ◦ あえてバッキバキに脆弱にしたプロダクトを、修正・強化する研修プログラム ◦ freeeのプロダクトセキュリティチームが”あえて脆弱化したサービス”を どうすれば守れるか、実践的なスキルを身につける ◦ 実際に攻撃をうける体験をすることで、セキュリティ意識を情勢してもらう プロダクト運用
43. 43 ⑤Hardening Program プロダクト運用 Private Network Shared System：zzz.zzz.zzz.zzz 会計 認証基盤 DB 人事労務 KVS Team A システム xxx.xxx.xxx.xxx application Team B システム yyy.yyy.yyy.yyy application 攻撃者 攻撃 ユーザX 登録 閲覧 ユーザY 登録 閲覧 通常 利用
44. 44 各フェーズでの取り組み 運用 開発 分析 IBへの 認証情報 取引データ 明細データ 個人情報 決算情報 業務データ
45. 45 freeeのデータ分析基盤 • データをフルに活用する ◦ KPIは毎日自動配信＆ダッシュボード化 ◦ ビジネスサイドだけでなく、全社KPI、エンジニアKPIなど多数 • いつでもクエリをかける ◦ 分析基盤は、社員アクセスOK ◦ 誰でもSQLのクエリでデータを分析することができる • データの匿名化、マスキング ◦ 分析対象データに顧客情報や重要情報を含ませない ◦ 安心してデータ分析ができる基盤づくり 分析
46. 46 顧客情報保護の前提 セキュリティレベルの定義 S 財務情報、取引情報、 マイナンバー、確認書類、 インターネットバンキングのログイン情報 etc... A その他の個人情報、匿名化した取引情報 etc... B 属性情報、統計情報 etc... ・リスクに合わせて、情報をレベル別に分類し管理 ・S/A情報を保護しつつ、B情報をうまく活用していくためには、どうすべきか
47. 47 3段階の環境（顧客情報と開発リスク） プロダクトのステージ ・個々の開発環境 ・テストデータのみ （顧客情報なし） 会計freee [Production] （本番環境） 会計freee [Staging] （動作確認環境） 会計freee [Development] （開発環境） ・社内動作確認環境 ・本番DBを 　定期的に匿名化コピー ・本番環境 ・顧客情報(S/A情報)は 　ここだけにある状態 ・GitHub 　レビュー ・自動テスト ・E2Eテスト ・動作確認 ・本番適用 　手順準備 社内で扱うに当たり、S/A情報（機密情報）をB情報（匿名化された情報）に加工する
48. 48 データマスキングの流れ プロダクトのステージ 会計freee [Production] （本番環境） 会計freee [Staging] （動作確認環境） ・定期的に本番からコピー ・コピー時に顧客情報を匿名化 　例：メールアドレス、事業所名etc ・ログ吐き出し時に 　重要情報はマスキング 　例：パスワード、マイナンバー freee分析基盤 (社員アクセス可) ・従業員は、顧客情報を気にせずに、分析基盤や動作確認環境を利用できる ・全社KPIの配信から過去データ分析まで活用の幅が広がる 従業員
49. 03 将来に向けての取り組み 49 Section
50. 50 課題はまだまだ山積み • よりデータを活用する未来のデータガバナンスは？ ◦ 機械学習、モデル構築にデータを与えるときの仕組み・枠組み ◦ コンプライアンス上はどうなる？ • Engの開発速度を落とさない ◦ 全部をGitHubに寄せられないか？GitOpsの実現を目指せ ◦ Amazon EC2上に開発環境を構築する • 継続的にリスク管理するには？ ◦ 内部不正・内部抑止をより防ぐ仕組み（統制）とその自動化 ◦ 開発エンジニアだけでなく、社内の課題とリスクを管理し、自動化する エンジニアリングがどんどん必要になる • サイバー脅威とコスト感 ◦ コストをかければ、検知・監視は強くなるが… ◦ 自社のサービスやデプロイ環境にあわせてカスタマイズ、チューニングする 将来に向けての取り組み
51. スモールビジネスを、 世界の主役に。