SAPセキュリティの「死角」を埋める EWA活用と塩漬け脱却の具体策：ベンダー依存のSAPセキュリティ その「死角」と「処方箋」

SAPシステムのセキュリティ不備は経営に直結するリスクです。本稿では「アーリーウォッチ・アラート」（EWA）を活用した効率的な脆弱性診断や、テストの標準化による「システムの塩漬け」脱却など、即座に取り組める具体的な処方箋を紹介します。

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

この寄稿連載について

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

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

　前回は、日本企業が抱えるベンダー依存やブラックボックス化といった構造的リスク、そしてセキュリティ担当とSAP担当の分断がもたらす死角について分析してきました。

　これら課題を解決し、SAPシステムを守り抜くためには専門知識が不可欠です。インフラやネットワークの一般論だけでは踏み込めない「SAP特有の領域」こそが、今まさに求められています。

　基幹システムの停止は深刻なインパクトをもたらします。裏を返せば、専門知識を具体的な防御策へと転換できれば、経営課題の解決に直結します。ここからは、実効性の高い具体的な「処方箋」を提示します。

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

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

アーリーウォッチ・アラート活用をお勧め

　アーリーウォッチ・アラート（以下、EWA）は、SAPシステムの基盤系エンジニアやパートナーの閉じた世界と思われがちです。マネジャーやアプリケーション寄りのメンバー、キーユーザーなどは難解なレポートという印象でしょう。ただ、このEWAは手早くコスパの良いセキュリティ対策としてお勧めです。自動診断によるユーザーシステムごとの独自レポートである点は見逃せません。

　EWAで見れる警告には次の様なものがあります。

• パスワードの強度が低い場合：　どのセキュリティ対策事項でも取り上げられる問題です
• 強力な権限のあるユーザーが多すぎる場合：　1つでも乗っ取られると、データの破壊や盗難、漏えいにつながります。強力な権限のユーザーは限定するのが得策です
• RFC（リモートファンクションコール）でのパラメータの問題点：　RFCは30年程前から使われているインタフェースのため、自由度が高く、暗号化対策やパラメータの与え方次第では脆弱（ぜいじゃく）性を生みます。EWAでユーザーシステムごとの設定の要注意事項を確認すべきです

　図1、2に代表的なEWAでのセキュリティ警告事項を掲載します。SAP専門家なら決して難しくない項目です。

図1　EWAによる脆弱性警告。強力な権限のユーザーが多過ぎる警告（提供：SAPジャパン）

図2　従来のレポート形式でのEWAによる脆弱性警告。青い丸で記したのがセキュリティ関連の警告（提供：SAPジャパン）

SAPシステムのセキュリティパッチ

　SAPが提供するセキュリティパッチ（図3）の適用は、ソフトウェアベンダーとしての責務であると同時に、ユーザーにとってもシステムの整合性と安全性を維持するための大前提です。サポートパッケージを常に最新の状態に保つことはIT運用の常識ではあります。

図3　SAPが提供するセキュリティパッチ（提供：SAPジャパン）

　SAPシステムが厄介なのは、停止が許されない重要基盤であることに加え、膨大なユーザーとインタフェースを抱えている点です。パッチ適用に伴う影響範囲の特定や動作確認には相応の習熟と経験が求められます。

　最近までSAPシステムはホストコンピュータの焼き直しという発想が強く、ハードウェア入替の数年〜10年に1度のタイミングでしかシステム更新をしない傾向がありました。この影響により、重要なセキュリティパッチが出ても即応が難しくしていました。

SAPシステムの更新サイクル

　今はオンプレミスを自前で運用するのではなく、変化即応型のクラウドサービスを使いこなすようになりました。

　日本では経済産業省の「2025年の崖」が発端となり、レガシ―IT資産が競争力の阻害要因になるという問題意識が芽生え始めました。最近はクラウドやAI、サイバーセキュリティ、DXなどのキーワードに象徴されるように、SAPシステムを数年〜10年単位で「塩漬け」にすることが当たり前ではなくなりつつあります。

　筆者がグローバルチームメンバーから聞く限り、SAPシステムの更新サイクルは2〜3年に1度がグローバル標準（あるいは欧米標準）と感じます。

システム更新に備える＝危機管理体制の構築

　必要なセキュリティパッチ（サポートパッケージ）を当てて脆弱性を少なくすることは危機管理そのものです。

　システムを塩漬けにしないための一般的な施策は「動作確認標準テストシナリオ」を持つことです。お客さまの例では、標準テストシナリオを持つことによってテスト期間とプロジェクト期間を3分の1に抑えたそうです。

　これ以外に筆者がユーザー企業から聞いたSAPシステムを塩漬けしないコツは下記の通りです。

• IT技術者を育てる意味でも塩漬けを避け、定期的・計画的に中小規模プロジェクトを計画する（伊勢神宮の式年遷宮の発想）
• 100％のゼロディフェクトを目指さない。システム更新後優先サポート期間1ケ月を設ける
• 動作確認標準テストシナリオはビジネス優先度が高い領域を手厚くする
• 日本のSAPスタッフより層の厚い欧州のSAPスタッフを中心にシナリオを実施する。日本では重要な意思決定を担い、実働は欧州中心にするという発想
• SaaSとまではいかなくとも、マネージドクラウドサービスのシステム更新やセキュリティ対策のサービスを最大限活用し、ベンダーの知見を生かす

　最近はライセンス買い取り型でなく、クラウド製品が一般的になってます。SAPシステムについても同様です。

　クラウド製品では24時間モニターや不要なアクセス権の整理、セキュリティパッチの適用支援、データセンターセキュリティ、第三者ベンダー製品のセキュリティ情報収集と対策などセキュリティ対策が多岐にわたります。

　また、「SAP Business Technology Platform」（SAP BTP）や「SAP Cloud ALM」といったIT基盤管理ソリューションではSSOや多段階認証、セキュリティモニタリングといった機能を実装しています。これらSAPの最新ソリューションの活用も選択肢に入れていただければと思います。

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