ERP セキュリティ要件 完全ガイド 2026：FISC基準・ISO27001・NIST CSF 対応の設計

ERP には会社の心臓部とも言える機密情報が集まっています。顧客名簿・財務諸表・人事データ・取引条件・原価情報。これらが漏洩すれば事業継続に致命的な影響を与えます。一方で、セキュリティを強化しすぎると業務効率が落ち、現場から「使いにくい」という声が上がる。このバランスをどう取るかは、ERP プロジェクトで最も難しい論点の一つです。

本記事では、業界別に必要となる規制要件、共通の必須対策、ERP セキュリティ設計の論理ステップ、Go-Live 後の運用、そしてセキュリティ事故が発生した時の対応プロセスまでを、現場の実装視点で整理していきます。

1. ERP セキュリティの本質 — 「機密情報の集約地」としての設計

ERP は、業務システムの中で最も多くの機密情報が集約される場所です。顧客マスタには取引先の連絡先・与信枠・取引履歴、人事マスタには社員の給与・評価・住所、財務データには月次決算前の経営数値が格納されています。これらが一箇所に集まっていることが ERP の利便性ですが、同時に最大の脆弱性でもあります。

ERP セキュリティの基本設計は、4つの柱で構成されます。アクセス制御（誰が何を見られるか）、暗号化（保存時・通信時の保護）、監査ログ（誰が何をしたかの記録）、インシデント対応（漏洩・侵害発生時のプロセス）です。この4つは、業界・規模を問わず必須で、いずれか欠けると重大事故につながります。

近年は4つの基本に加えて、ゼロトラスト原則（社内外を問わず全アクセスを検証）とサプライチェーン対応（取引先システム経由の侵害対策）が新たな要件として加わってきました。ERP は社外システムとの連携が増える一方で、攻撃面も広がっているのが現状です。

2. 業界別の規制要件 — 自社業界の標準を押さえます

業界によって、ERP セキュリティに求められる規制水準が大きく異なります。最初にやるべきは、自社業界の規制要件を整理することです。これを曖昧にしたままセキュリティ設計を進めると、後で監査・査察で問題になります。

3. 金融業界 — FISC 安全対策基準への対応

金融業界ではFISC（金融情報システムセンター）の安全対策基準が事実上の標準です。最新は第13版（2025年3月公表）で、統制・実務・設備・監査の各基準にわたり数百項目に及ぶ詳細な要件があります。第13版では、2024年10月公表の金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」を踏まえた項目や、AI 利用における安全対策の基準が新設されました。銀行・証券・保険会社は監督官庁の検査でこの基準への準拠状況がチェックされます。

クラウド利用時は、ISMAP（政府情報システムのためのセキュリティ評価制度）認証クラウドを選ぶのが標準です。AWS、Azure、Google Cloud、Salesforce、SAP RISE などが ISMAP 認証を取得しています。FISC 準拠の SAP / Oracle 構築では、ハイパースケーラーの選定もこの観点が必須になります。

具体的な実装ポイントは、強固な多要素認証（MFA）の必須化、特権 ID 管理（PAM ツールの導入）、データセンター物理セキュリティの確認、四半期ごとの脆弱性診断です。Aurant が支援した銀行系 ERP プロジェクトでは、FISC 準拠を前提に設計するだけで初期コストが 1.5〜2倍に膨らむ実態がありました。

4. 医療業界 — HIPAA + 3省2ガイドライン

医療業界では、海外向けのHIPAA（Health Insurance Portability and Accountability Act）と国内の3省2ガイドライン（厚労省「医療情報システムの安全管理に関するガイドライン」、経産省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」、総務省「クラウドサービス事業者が医療情報を取り扱う際の安全管理に関するガイドライン」）への対応が必要です。

患者情報の「保存時暗号化」「通信時暗号化」「アクセスログ全件保管（最低5年）」「データ持出制限」が中心テーマです。クラウド利用時は、ハイパースケーラーが「医療情報安全管理ガイドライン準拠」を明示している必要があります。AWS、Azure は医療業界向けのコンプライアンスサービスを提供しており、Google Cloud も近年強化しています。

医療業界での失敗事例として頻発するのが、「USB メモリでの患者データ持出」による情報漏洩です。技術的対策（USB 接続制限、データ持出ログ）だけでなく、職員教育の継続が必要になります。

5. 公共・行政 — ISMAP 認証必須

公共・行政システムでは、ISMAP 認証クラウドの利用が政府クラウド調達で必須になっています。AWS / Azure / GCP の主要リージョン、Salesforce、SAP の RISE などが ISMAP 認証を取得しています。地方自治体システムでも、ISMAP 認証クラウドを選定する流れが広がっています。

政府情報システムでは、さらに政府情報システムのためのセキュリティ評価制度（IPA が運営）と、政府情報システムにおけるクラウドサービスの利用にかかる基本方針（クラウド・バイ・デフォルト原則）への準拠が求められます。これらの規制は毎年改訂されるため、最新版を継続的にウォッチする必要があります。

6. 製造業・流通 — ISO 27001 + NIST CSF

製造業・流通業では、国際標準のISO 27001と米国フレームワークのNIST Cybersecurity Framework (CSF) 2.0が標準です。これらは強制ではありませんが、グローバル取引先からの要請として認証取得を求められるケースが急増しています。

近年特に重要になっているのがサプライチェーンセキュリティです。取引先システム経由での侵害（サプライチェーン攻撃）が増えており、自社だけでなく主要取引先のセキュリティ水準もチェックする必要があります。SBOM（Software Bill of Materials）の管理、取引先のセキュリティ監査、共通インシデント対応プロセスの整備が要件になっています。

7. 共通の必須対策1 — アクセス制御（RBAC + ABAC）

ERP のアクセス制御は、ロールベースアクセス制御（RBAC: Role-Based Access Control）+ 属性ベースアクセス制御（ABAC: Attribute-Based Access Control）の組み合わせが標準です。役割（経理担当、営業マネージャー、人事部長など）でアクセス権を割り当て、さらに組織所属・役職・地域などの属性でも条件付けます。

SAP / Oracle / NetSuite には標準で RBAC 機能があり、職務分掌（SoD: Segregation of Duties）の自動チェックも組み込めます。SoD は、例えば「同じ人が発注承認と支払承認の両方をできてはいけない」というルールで、不正防止の基本です。SAP には GRC（Governance, Risk, Compliance）モジュールがあり、SoD 違反を自動検出できます。

実装上の注意点は、ロールの粒度設計です。粒度が細かすぎるとロールが数千に膨らみ管理不能、粗すぎると不要な権限が広がる、というトレードオフがあります。実装現場では、業務の役割を 30〜50ロール程度に整理するのが妥当な水準です。

8. 共通の必須対策2 — 暗号化と鍵管理

暗号化は「at-rest（保存時）」と「in-transit（通信時）」の両方で必須です。クラウド ERP では、ハイパースケーラーが提供する暗号鍵管理サービス（AWS KMS、Azure Key Vault、Google Cloud KMS）を使うのが標準です。これらは FIPS 140-2 認証取得済みで、規制要件も満たします。

金融・医療・公共のような機微業界では、「BYOK（Bring Your Own Key）」で自社管理の暗号鍵を使う構成も検討します。BYOK にすると、クラウド事業者でもデータを復号できなくなります。一方、運用負荷は増えるため、本当にそこまで必要かは個別判断です。

9. 共通の必須対策3・4 — 監査ログとインシデント対応

監査ログは、全ての重要操作（ログイン、データ参照、データ変更、権限変更、エクスポート）を5〜7年保管するのが標準です。SAP / Oracle / NetSuite には標準ログ機能があり、SIEM（Splunk / Microsoft Sentinel / IBM QRadar）と連携してリアルタイム異常検知を組みます。

個人情報保護法改正（2022年4月施行）で、個人情報保護委員会への漏えい報告（速報：おおむね3〜5日以内、確報：30日以内、不正アクセス等による場合は60日以内）と本人への通知が義務化されました。「72時間以内」は EU の GDPR の基準で、日本の個情法とは期限が異なる点に注意が必要です。社内のインシデント対応プロセスを事前に文書化し、年1回の訓練を実施します。Aurant が支援する案件では、CISO（最高情報セキュリティ責任者）からエンジニアまでが参加する想定訓練を実施し、指揮命令系統と連絡経路を実地で確認することを推奨しています。

10. 失敗パターン — 「ベンダー任せ」「ログ取得不在」

ERP セキュリティが破綻する典型は2つあります。1つ目はベンダー任せで、SI ベンダーがセキュリティ設定をデフォルトのまま納品し、業務側が要件を理解しないまま運用するケースです。事故が起きてから「これは設定していなかったのか」と気付いても遅く、業務影響が大きくなります。打開策は、自社セキュリティ部門が要件定義段階から参画し、SI ベンダーの納品物をレビューする仕組みを作ることです。

2つ目はログ取得不在で、監査ログの取得設定をしておらず、インシデント発生時に何が起きたか調査できないケースです。SAP / Oracle のデフォルト設定では一部のログが無効化されており、明示的に有効化する必要があります。Go-Live 前に「全主要操作のログが取れているか」をチェックリストで確認するのが必須です。

11. まとめ — 自社にとっての判断軸

判断のコツは、「業界規制を最初に確認」「アクセス制御 / 暗号化 / ログ / インシデント対応の4点セット」「年1回の訓練実施」の3点です。セキュリティ設計は ERP プロジェクトの最初から織り込むのが最もコスト効率が高く、Go-Live 後の追加対応は数倍のコストがかかります。Aurant Technologies では ERP セキュリティ設計のアセスメントから運用設計まで、業界別の専門知見を踏まえたご支援を提供しています。お気軽にご相談ください。