第５回 SAP移行とセキュリティ・バイ・デザイン対策【セキュリティ・バイ・デザインなき業務基盤にDXは成しえない】

２.  セキュリティ・バイ・デザインの具体的な内容
 

２－１.  セキュリティ・バイ・デザインとは何か
  
セキュリティ・バイ・デザインとは主に以下3つの要件を満たしたシステム対策を取ることを指します。

• インシデントが発生してから事後的に取り組むのではなく、事前に予防的に対策を実施する
• ゼロトラストセキュリティなどのセキュリティの思想を企画段階から盛り込み、その後の要件定義、設計、構築、開発、テスト、運用保守というシステムライフサイクルの全フェーズで一貫したセキュリティ対策を実施する
• 各システムの特性や重要度に応じて過不足なく対策を行い、対策のリスク評価・管理を実施する

昨今よくあるSAPのシステム構成を元に具体策を挙げてみましょう。

SAPは過去とは異なり、オンプレに構築されるだけではなく、IaaSやPaaS上に構築される例や、Concurを始めとしたSaaSのコンポーネントとの接続も多く見られるようになりました。

従って、SAPのセキュリティについて考えなければならないポイントが増えています。

またそれに加えて、利用経路も、インターネットからの直接利用や、モバイルなどの多種多様なデバイスからの利用が増えており、アクセス管理に対するセキュリティ対策も重要となっています。

２－２.  インフラストラクチャーレイヤーのセキュリティ対策
 
最初にインフラストラクチャーレイヤーでの考慮点を例示したいと思います。

インフラストラクチャーレイヤーではSAPが構築されるインフラ（IaaSやPaaS、オンプレ）のセキュリティおよびアクセス管理に対するセキュリティ対策について述べます。

まずはIaaSやPaaSの管理ですが、「自社のセキュリティ管理責任範囲」がどこにあるかを把握することが重要です。

構成管理、ソフトウェアバージョン管理、ネットワークセグメントの管理、格納データの暗号化、管理者やシステム間連携ユーザなどの特権アクセス管理らが含まれますが、どのようなコンポーネントを利用するかによって、サービス提供ベンダーと自社側の責任範囲が変わってきます。

「責任共有モデル」などの名称で各ベンダー（AWSやMicrosoft、SAPなど）から明示されているため、まずはここを確認し、どのコンポーネントで、どの範囲の責任を自社が有するのか把握するところから始めることが必要です。

その後は、それぞれのインフラの構成管理（NW、OS、DBなど）、特権ユーザ（サーバのAdministrator、DBのSYS、SaaSであれば構成管理のできる管理者ユーザなど）の管理やセグメント構成、暗号化の設定などについて検討します。

ネットワークのセグメント構成、各データの暗号化、各サーバおよびソフトのバージョン管理の方針策定・管理を疎かにすると、デフォルト設定を悪用されるなどの脆弱性をついたサイバー攻撃を受けやすくなり、さらに暗号化されていないデータであれば、容易に機密データを閲覧されてしまいます。

昨今では、CSPM（Cloud Security Posture Management）製品を導入することで、クラウドサービスの設定を一元的に常時監視および違反時のアラート発出、早期修正することができます。

また、特権アクセス管理は従来の手作業での台帳管理などではなく、システム的に管理、都度の貸出とし、申請承認・操作の記録および利用後のパスワード（または証明書、アクセスキー）変更作業まで行えるようなソフトウェアの利用が広まってきています。

社内リソースであるオンプレについては、上記の設定監視に加えて、物理的対策として、データセンターや自社サーバルームの入退室管理も必要になります。

また、有事の際の原因特定や被害影響の調査のための適切な各種システムログの設定・管理、速やかなデータリカバリのためのバックアップ方針策定・管理も考慮しなければなりません。

次にアクセス管理側に目を向けると、多様なデバイスそれぞれのOS・アプリケーションなどの端末セキュリティ管理や、それらが使用する通信ポート、通信経路の監視も必要になります。

これらが不十分な場合、セキュリティリスクのあるアプリケーションの私的利用（シャドーITの利用）などにより、意図しない情報漏洩が発生する可能性があります。

またセキュリティポリシーとして許可しているクラウドサービスであったとしても、通信ポートの監視を行わないと、機密データをアップロードされるなど、情報の持ち出しが起きる可能性もあります。

これらへの対策としては、ユーザのSAP利用シナリオを明確化し、SWG（Secure Web Gateway）、CASB（Cloud Access Security Broker）などのセキュリティ製品を導入することで、ユーザ端末からのアップロードデータや閲覧するWEBサイトの監視するのが効果的です。

また EMS（Enterprise Mobility + Security、EMMとも）製品を導入することで、各種端末やアプリケーションの管理、さらには機能の制御を行うこともできます。

加えてセキュリティ診断サービスやウイルス検知ソフトの導入、定期的なユーザトレーニングも別途行う必要があります。

このようにインフラストラクチャーレイヤー一つをとってみてもセキュリティのポイントが増えており、構想の段階からセキュリティを意識することが非常に重要になります。

２－３. アプリケーションレイヤーで取り組まなければなければならないこと 

次にアプリケーションレイヤーでの考慮点を例示します。

このレイヤーでは、アプリケーションに対しての権限や、業務処理における不正（職務分掌違反、役割を超えた機能の実行など）を防止する観点が必要となります。

SAPに関して言えば、内部統制機能や不正取引検知機能など、様々な仕組みを提供しているSAP GRC（Governance・Risk・Compliance）を導入することで一元的に対策を取ることができます。

以下に一部機能をご紹介します。

・SAP GRC AC（Access Control）

SAPロールの申請・変更、およびロールの職務分掌違反をチェックするための機能です。

職務分掌のルールセット設定、特権ユーザ管理、ロールマスタデータ管理、ユーザ申請・変更のワークフロー機能を持ちます。

これにより、過剰または不要な権限を与えられているSAPユーザによる個人情報や機密データの窃取、SAPシステム設定の改ざんなどの被害を防ぐことができます。

・SAP GRC BIS（Business Integrity Screening）

膨大なSAP取引データから企業組織内の不正取引を洗い出し、分析するための機能で、不正取引条件の開発、自動検出、調査履歴の記録などの機能を持ちます。

これにより、社員または請負業者の過失、あるいは内部犯行による不正会計損失を効率的かつ効果的に検出することができます。

また別途、機密データへの不正アクセスやSAPシステム設定の改ざんなどを検出・監視するためには、SAP監査ログの設定・管理も必要になります。

このようなSAPの機能導入や設定は有事の際に利用する事後だけではなく、定期的にチェックを行うことで事前に兆候を検出することを目的とします。

さらにSAPと独自の開発プログラムとのシステム連携もポイントとして挙げられます。

開発フェーズの段階で、プログラム内に悪意のあるコードが含まれるリスクが考えられます。

開発環境やリポジトリの権限管理で対策を取ることもできますが、新しい開発技術を制限してしまう可能性もあり、セキュリティ・バイ・デザインの一環として、開発委託先との充分な協議が必要になります。

またインフラストラクチャーレイヤーと同じく、SAP上も有事の際のため、適切な各種システムログの設定・管理、バックアップ方針策定・管理が必要です。

３.  企業が検討すべきこと

上記で見てきた通り、経営に直結し、個人情報や知的財産など機密データも取り扱う基幹システムはインフラストラクチャーレイヤーからアプリケーションレイヤーまで、多岐にわたる対策が必要になります。

DXの推進や2027年問題という外部要因など、基幹システム変更のきっかけは様々ではありますが、これらの刷新はセキュリティ・バイ・デザインに基づくセキュリティ事項の見直しに真剣に向き合う良い機会なのではないでしょうか。

本来の目的である経営情報の統合・利活用といった業務変革やDXの推進を図る上で、顧客・取引先・従業員といった方々の利便性を高めていく上で、外部からのサイバー攻撃や情報漏洩などの予期せぬ事態に足をすくわれてしまうようなことは、絶対に避けなくてはなりません。

基幹システムの変更を契機に、セキュリティ・バイ・デザインのような一貫したコンセプトに基づき、大切な情報資産を守ることが企業に求められていると考えております。

関連ページ

・デロイト トーマツ グループのサイバートップページ

本連載のバックナンバー

・第１回 Cyber Everywhereの時代に求められる対応（GREAT RESET IN Cyber Security）

・第２回 ESGにおけるサイバーセキュリティ【ESG投資及びディスクロージャーとCyberについての考察（投資家等外部ステークホルダーからの要請）】

・第３回 サイバーインシデントに関する開示の国際動向【米国証券取引委員会（米国SEC）のサイバーセキュリティ開示の規則案への対応準備について】

・第４回 M&Aにおけるサイバーセキュリティ

・第６回 「投資」に値する効果的なサイバーセキュリティ対策【サイバーセキュリティ × データアナリティクス専門家の必要性】

・第７回  情報安全保障に関する提言【真偽不明な「情報」が満ち溢れる昨今のデジタル社会における「情報」に関する問題点と必要なリスク対策とは？】

・第８回  クラウドセキュリティ態勢とガバナンス強化【情報セキュリティガバナンス態勢強化に向けたアプローチ】

・第９回  転換期を迎えている“サイバーセキュリティに関する委託先管理”の概念・捉え方【適切な委託先選定、委託先モニタリングを通じた委託先管理】

・第10回  サイバーリスクの高まりに対する内部監査の役割【DXに伴うサイバーリスクの高まりにおいて、内部監査の役割重要度が増大】

・第11回  デジタル時代におけるIT-BCP必要性の高まり【IT-BCP整備のポイント】

・第12回  断絶の時代をリードするシフトレフト〜ビジネスにアジリティをもたらすDevSecOps〜

・第13回  地方公共団体DXに伴うサイバーリスクの高まり～地方公共団体におけるセキュリティ対策～

・第14回  地方公共団体のGovCloudの移行後の必要なセキュリティ対策【基幹業務のクラウド化に伴う必要なセキュリティ対策に関する考察】

・第15回  スマートシティ推進における個人データの保護・活用