なぜSAPシステムはセキュリティの空白地帯になる？ 日本企業が抱える構造的リスクを解説：ベンダー依存のSAPセキュリティ その「死角」と「処方箋」

サイバー攻撃の標的が基幹系へ拡大する中、日本特有のベンダー依存や塩漬け運用により、SAPシステムがセキュリティの空白地帯となっています。本稿では、攻撃者に狙われる背景や経営インパクトを解説し、対策に向けた課題を整理します。

[木下史朗，SAP ジャパン]

この寄稿連載について

サイバー攻撃の標的が情報系から基幹系へと拡大し、企業の「経営の心臓」であるSAPシステムが脅威にさらされています。しかし、日本特有の「ベンダーへの依存」や「塩漬け運用」という慣習が、誰も責任を持たないセキュリティの空白地帯を生み出し、ビジネス停止のリスクを高めています。

本寄稿連載は、SAPシステム責任者・セキュリティ責任者の両面から見たアプローチ方法を解説します。標準機能を使った現状把握や、SaaS移行によってセキュリティ責任をベンダーへシフトさせる方法など、組織がこの危機を乗り越えるための方法を示します。

　近年、ようやくSAPシステムを含む業務基幹システムでもセキュリティ対策が重要なテーマとして認識されるようになりました。SAPに関するセキュリティの問い合わせ件数は年々増加しており、関心の高まりを肌で感じています。

　一方で、インフラ環境やPC、物理的セキュリティ対策などと比べると、基幹システムのセキュリティ対策は一般化が難しく、取組みにバラつきがみられます。SAPシステムも、侵入を許してしまったがハッキングまでに至らなかった事例や、攻撃をうまく防げた事例などの報告から、有効な対策手段が数多く見えてきています。

　本連載では、SAPシステムを例にセキュリティの考慮点や有効な施策について紹介します。SAPシステム以外のパッケージや開発環境との相違点はあるものの、共通項として参考になるポイントは多いかと思います。

著者プロフィール：木下史朗氏（SAPジャパン　カスタマーサクセスパートナー）

日系製メーカー・外資系メーカーを経て2000年にSAP入社。SAPジャパンでコンサルタント、プロジェクトマネジャー、新規事業開発に携わる。2011年よりSAPグローバルチームに異動し、オンプレミス顧客のアップグレード＆サポートプログラム推進役。2016年よりSAPアジアパシフィックジャパンチームに異動し、SAP顧客のクラウド移行プログラムの推進役として現在に至る。

SAPシステム2つの提供形態

　SAPライセンスを「買い取り型（図1上段）」で契約し、オンプレミスやIaaSで運用している場合、サイバー攻撃への備えはユーザー企業が主体となって実施する必要があります。しかし、個別のQ＆A対応だけでは解説が断片的なものになりがちです。

　そこで、具体的な対策の是非を論じる前段として、SAPシステムのセキュリティ対策の全体像と今後取るべき方向性を整理します。

　SAPが推奨するのは、アプリケーションからDB、ミドルウェア層までをトータルでカバーし、セキュリティに定評のある「SAPクラウド（図1下段：　SaaS型・マネージド型）」です。しかし、本稿は現在オンプレミスなどで運用している多くのお客さまにとっても、今後のセキュリティ検討の出発点として参考にできる内容となっています。

図1　ライセンスの買い取り型とサブスクリプション型で対策が異なる（提供：SAPジャパン）

攻撃者から見たSAPシステムと被害による経営インパクト

攻撃者から見たSAPシステム

　なぜハッキング被害が後を絶たないか。それはSAPシステムが「身代金ビジネスの対象として十分に成り立つ」「データ転売目的といった大きなビジネスチャンスがある」という2つが主な理由とされています。

　SAPシステムで受注や引当、納期回答、出荷、会計締め処理など、絶対止めてはいけない仕組みを採用している限り、身代金のターゲットになるものとして十分に注意を払う必要があります。

　SAPシステムの更新プロジェクトのダウンタイムは年々厳しくなっており、3日以上止めるのは至難の業です。生命線を担うシステムだからこそ、SAPシステムは攻撃者にとって身代金ターゲットとなりやすいのです。

　データ転売目的としてのSAPシステムへの攻撃はどうでしょうか。人事システムをSAPシステムで運用している場合や、BtoCの顧客情報を持っている場合は特に気を付けなければなりません。BtoBの取引情報はニッチな情報であるため解釈の難易度は高いものの、使われ方によってはリスクになります。

サイバー攻撃と経営へのインパクト

　SAPシステムや基幹システムがハッキング被害を受けた場合、そのダメージは想像以上に膨らみます。出荷が止まることで会社の業績に与えるダメージや、取引先のサプライチェーンに対する影響、身代金要求対応、社会的信用へのダメ―ジ、顧客離れ、株価下落などのリスクも考えられます。

　具体的な施策への落とし込みは各社各様です。IT関係者の報告方法や経営者の理解度によって対応は大きく異なるという印象を受けます。

図2　ビジネスインパクトが大きいシステムの特徴（提供：SAPジャパン）

SAPシステム特有の課題

なぜSAPシステムのセキュリティ対策が漏れているか

　セキュリティ対策漏れは、SAPシステムへの理解がSAP担当者で閉じてしまっていることに起因しています。英語の記事を読んだり他国の同僚と話したりするとグローバル共通の課題であると感じます。

　企業のセキュリティ責任者、担当者の業務は一般的に以下に挙げるようなものが考えられます。

• ファイアウオールの導入、対策ソフトウェアの導入
• BCPの策定、実施
• 監視カメラやセキュリティカード
• アクセスログ監視や侵入検知、日々のインシデント管理と対策
• 監査対応
• 従業員教育
• ベンダー管理、契約見直し

　こうした業務を日常的に担うセキュリティ責任者の立場から見ると、SAPシステムをどの項目として扱うべきか判断に迷います。SAPシステムは技術的な独自性が高く、その内容を十分に理解するには、SAPに精通した技術者の知見が必要となります。

図3　セキュリティチームとSAPチームに距離がある背景（提供：SAPジャパン）

専門知識が必要なSAPシステム　SAPが責任を持つという誤解

　「SAPシステムはSAPがなんとかしてくれる」と誤解しているケースも見受けられます。SAPシステムは独自のプロトコルを採用しており、その堅牢（けんろう）性には定評があります。設計も外部から容易に不正な操作ができないよう配慮されています。

　一方で、高額な投資をしたにもかかわらず、SAPシステムに関する知識や運用を過度に外部へ依存してきた結果、「SAPシステム自体がブラックボックス化してしまっている」「SAPシステムは閉じた世界で、必要なデータを取り出すこと自体が難しい」といった声をユーザー企業から聞くことがあります。実際、SAPアプリケーションを介さなければSAPシステムのデータベースの内容を正しく理解することは容易ではありません。

　こうした背景もあり、一般のセキュリティ責任者や担当者から見ると、SAPシステムは「独自プロトコルや厳格な権限管理によって守られている領域」、あるいは「手を入れたくてもどこから着手すればよいのか分からない領域」と受け止められているのではないでしょうか。

　SAPシステムの権限やパスワード、SSO、セキュリティパッチ適用などの仕組みはSAPが提供しますが、どのように対応するかはユーザーが考える必要があります。

　SAPシステムを担当している方であれば既にお気付きかもしれません。つまり、SAPのSaaS型、マネージドサービス型クラウドで使っている場合を除き、SAPシステムは基本的に顧客が自社の責任で運用していくもので、自社の責任でセキュリティ対策をする必要があります。

　例えばSAPシステムの権限で「SAP_ALL」という権限があります。SAP_ALLは、取り扱いに十分に注意しないといけない「スーパー権限」ですが、この意味はSAP関係者以外には十分に理解されていません。この他にも、不正に利用された場合に重大な影響を及ぼしかねない強力な権限が幾つか存在しており、権限設計や運用には十分な配慮が求められます。

　また、RFC（リモートファンクションコール）と呼ばれる25〜30年以上前から使われてきたSAPシステムへのインタフェース技術があります。環境が激変した現在、もっと堅牢で使いやすいインタフェースは多々提供されていますが、古い方法を採用している企業が多いため、全面的なインタフェースの切り替えを強制していません。

　これら旧来のインタフェース技術を使う際も使い方やパラメータの与え方次第では、リスクになることがあり注意が必要です。こうした課題は日本固有のものではなく、グローバルに共通するものです。

日本特有の課題

外部ベンダー頼みの日本のITの特殊性

　以前、日本のIT技術者のうち約7割がITベンダーに在籍、ユーザー企業はわずか3割程度という話が話題になりました。「DXブーム」や「AIブーム」で多少は変化したかも知れませんが、今も大きく変わってないという印象です。

　SAPシステムのセキュリティを守る上で重要な、権限管理やセキュリティパッチの判断、SSOへの対応などは、ベンダーの力を借りざるを得ないというのが現実です。この点もSAPセキュリティを取り巻く状況をより難しくしています。

　ベンダーはビジネスとして顧客と取引をしている関係上、どうしても顧客の事情について当事者意識が弱まってしまうものです。これはベンダーが悪いという話ではなく、契約関係に基づくビジネスである以上、構造的な部分といえるでしょう。

　この構造はSAPシステムの世界でも同様です。いわゆるSAPパートナーと呼ばれるITベンダーが非常に大きな力を持っている点は、他国と比較しても特徴的です。発展途上国やIT人材が貴重な国では見られるものの、先進国においては一般的ではありません。

経営者がSAP導入を決定した国々と旧システム置き換えでSAPを選んだ日本

　欧米を中心に「SAPシステム＝経営システム」と位置付けけられており、経営者が迅速かつ的確に数字を把握するための基盤としてSAPシステムを導入するのが一般的です。

　日本の経営者の多くは、経営革新が目的というより、老朽化した旧システムの刷新（リプレース）をきっかけにSAPを導入しています。自社開発より効率的というベンダーの提案を受け、実態としては「便利な開発テンプレート」としているのではないでしょうか。欧米の経営者がSAPシステムを自社の生命線と捉えている一方で、日本の経営者はSAPシステムへの理解が希薄です。

　日本語のコミュニケーションでSAPシステムを導入、運用ができてしまうのは素晴らしいことですが、英語圏やグローバルの情報が入ってきにくいという難点もあります。英語を介してSAPシステムを導入、運用するのが一般的な国と比べると、日本語圏はやや異なる道を歩んできたとも言え、一長一短があります。

セキュリティ責任者とSAPシステム責任者の相互協力の必要性

　サイバーセキュリティとSAPシステムの両方に長けた技術者はめったにいません。これは日本だけでなくグローバル共通の課題です。サイバーセキュリティチームがインシデント管理や監視などの施策、BCP施策、従業員教育施策などを検討する際は、SAP技術者側からもSAPシステムに焼き直した場合はどういう施策が適切なのかといった積極的な協調体制が必要です。

　SAPの本質的な価値は日本の経営者に伝わりにくいのが実態です。しかし、セキュリティリスクへの対応という文脈であれば、経営課題として正しく認識され、決裁が得られやすかった実例が複数存在します。受注や引当、出荷や締め処理など重要プロセスを絶対に止めないようにSAP担当側からも積極的に関与するのが望ましいと言えます。

　日本特有の技術者がベンダーに偏っているという課題の解消はなかなか解決が難しいので、SaaS型やマネージドサービス型クラウドを使ってベンダーのセキュリティ対策をサービスとして活用するという方法もよいでしょう。

図4　セキュリティチームとSAPチームに求められるアプローチ（提供：SAPジャパン）

　以上、さまざまなSAPシステムのセキュリティの課題を分析してきました。これ以降は、SAPシステム経験者が取り組むことができる、具体的な施策について説明します。

※SAP、SAPロゴ、記載されている全てのSAP製品およびサービス名はドイツにあるSAP SEやその他世界各国における登録商標または商標です。