SAP ERPの概要
SAP ERP（Enterprise Resource Planning）を導入している組織にとって、SAP ERPは多くの場合、最も重要な基幹システムの1つとなっています。SAP ERPは、顧客からの注文を受け付けて処理し、請求と追跡を行って、財務データを経営層や投資家に提供します。つまり、ビジネスを支える基盤です。SAP ERPで障害や侵害が起きれば、事業が止まってしまう可能性があります。
その重要性にもかかわらず、一部のSAP ERP環境では、最新のクラウドやSaaSのソリューションで広く採用されるゼロトラストセキュリティ基準にまだ十分に対応できていません。大抵は、SAPの柔軟性が原因であり、2つの導入形態が同一でないため、変更には多くの場合、専門的な労力が大幅に求められることを意味します。
SAPセキュリティをさまざまな視点から深く経験してきたアイデンティティアーキテクトとして、SAP ERPの導入環境を最新化し、最新のセキュリティの利点を活用できる方法についての見解をご紹介します。
一般的な問題・課題
将来像の姿について掘り下げる前に、改善のチャンスが大きい代表的な領域についていくつか見ていきましょう。
命名規則と用語
SAPのような大規模なベンダーと連携する場合、適切な用語や命名規則を正確に把握することは難しいものです。正規のSAPテクノロジーを扱っていることをしっかりと示したかったため、このブログに相応しいタイトルを見つけるのは苦労しました。
SAPは幅広い製品を提供しており、新しい製品の中には、ここで取り上げる内容とは異なるモデルに基づくものもあります。この記事でSAP ERPと言う場合は、SAPが1972年以降に構築・拡張してきた製品スイートを指します。通常、このスイートは、ABAP、S4/HANA、ECC、Basis、Netweaverといったキーワードで特定できます。
レガシー認証
SAPはWebユーザーインターフェイステクノロジーで進歩を遂げてきましたが、組織は、SAPGUIなど従来のWindowsクライアントを通じてSAPにアクセスすることが今でも一般的です。SAPGUIでもゼロトラスト認証は可能ですが（詳細については後述）、導入と構成は容易ではありません。その結果、多くの組織が認証にパスワードを使い続けています。
パスワードには、おなじみの課題がすべて伴います。それは、最適とは言えないユーザーエクスペリエンス、パスワード同期ツールの必要性、そして保証レベルの低い認証方法です。
しかし、最大の懸念事項はユーザーエクスペリエンスではなく、潜在的なセキュリティリスクです。SAPGUIでは、ネットワーク暗号化は認証と密接に結びついています。これは、多くの導入環境で、ユーザー名とパスワードが平文で内部ネットワークを通過することを意味します。パスワード同期ツールを使用している場合、Active Directoryのパスワードが公開される可能性もあります。そして、Entra IDハイブリッドモードが有効になっている場合は、同様のリスクがEntraの認証情報にまで及ぶ可能性があります。
VPNの利用やWindows認証の有効化によって、このリスクをある程度軽減できますが、完全な解決方法ではありません。真のゼロトラスト戦略では、ネットワークが侵害されていることを前提とし、ネットワークベースの保護のみに頼ることなく、あらゆるレイヤーで強力な認証を適用します。
不完全なRBACプロジェクトと構成ドリフト
SAPの権限モデルは、非常に詳細かつ複雑です。私が管理者としてキャリア初期の頃、SAPのセキュリティと権限に関するADM940コースを学ぶ必要がありました。軽い内容ではありませんでしたが、SAPのセキュリティの仕組みを教えてくれるものでした。
SAPのセキュリティは、多くの場合、トランザクションコード（Tコード）という、それぞれの業務タスクに関連付けられたもので考えられます。しかし、すべてのユーザーアクションの裏側では、数十から数百もの個別の権限がチェックされます。これらの権限チェックは、ユーザーの状況や導入されているSAPのバージョンによって異なる場合があります（詳細は後述）。
複雑さも問題ですが、規模もまた別の問題となります。SAP内のロールの複雑さを確認したところで、次は規模について見ていきましょう。多くのロールベースアクセスコントロール（RBAC）プロジェクトでは、専用の職務ロールですべてのアクセスを網羅しようとすると、障壁に直面します。この非現実的な目標を追求すると、ユーザー数とロール数がほぼ1対1の関係になる可能性があります。この問題は、SAPの導入環境に特有のものではありませんが、さまざまな形で表面化し、SAPの状況を複雑化させる要因となり得ます。
SAPには、ロール管理のためのツールが用意されており、一貫して使用すると大いに役立ちます。しかし、多くの環境では、一貫性が保たれることはまれです。あるSAPシステムで機能することが、別の場所では同じように機能しないことはよくあります。
その結果、多くの組織は、アクセスを割り当てる際に保証レベルの低い方法に頼ってしまいます。
- 既存のユーザーからコピー：SAPには、この「モデル化」という機能が搭載されています。
- アクセスは、トランザクションコード（Tコード）に基づいて割り当てられます。Tコードは、特定のロールのアクセスレベルを決定する単純化された方法です。
どちらのアプローチにも課題が伴います。既存の担当者に基づいてユーザーをモデル化すると、時間の経過とともに蓄積された不適切なアクセスを引き継いでしまうリスクがあります。Tコードでは、ユーザーが何ができるかについて、一部しか示していません。さらに、Tコードは直接割り当てられるという誤解がよくありますが、実際にはできません。そして、新しいSAPモジュールはTコードに基づいていないため、この方法は徐々に使われなくなっています。
以前にも繰り返された状況
この問題に対して、さまざまな解決方法がこれまでに幾度となく採用されてきた（そして今なお使用されている）ことは、驚くべきことではありません。ID管理やアイデンティティガバナンス関連の製品が、どのように部分的な解決方法として使用されてきたかを示す例を次に示します。
コンポーネントの概要
注：これらのコンポーネントには、あえて一般的な用語を使用しています。非常に多くの場合、アイデンティティ関連の製品はこれらの機能を複数兼ね備えています。
エンタープライズディレクトリーサービス
このコンポーネントは、実行時におけるアクセスコントロールサービスを担います。ローカルのSAP認証が行われる場合は、ここでユーザーのパスワードが同期されます。 SAPでSSOが構成されている場合では、レガシーKerberos認証サービスがこのコンポーネントによって提供されます。
エンタープライズプロビジョニングサービス
このコンポーネントは、ロールベースのアクセスコントロールの実行と、環境全体におけるアクセスのプロビジョニングを担います。このサービスは、適切なユーザーアカウントが適切なシステムに設定されて、ディレクトリーサービスを含めて、それらのアカウントに適切なアクセス権が設定されるように支援します。
SAP GRCモジュール
このモジュールは、グローバルプロビジョニングサービスからSAPの自動プロビジョニングの引き継ぎ、職務分掌チェックの実施、そして要求されたSAPアクセスに対する適切なアクセス承認の取得など、多くの機能を担います。
この設計は、コンプライアンス要件を満たすのに役立つ一方で、導入の成功を制限しかねない課題もいくつか抱えています。
- SAPアクセスに対する承認は、他のエンタープライズアプリケーションに対する承認とはまったく異なります。つまり、監査システムが異なり、管理者向けのワークフローエンジンが別にあり、承認者向けの承認プロセスも別に存在することになります。また、承認者が処理を迅速に行わない場合、ユーザーにとって理解しにくいユーザーエクスペリエンスとなり、混乱を招く可能性もあります。
- エンタープライズプロビジョニングサービスでは、各SAPシステムに存在するアクセスを完全に把握できません。SAP GRCには、それ自体と個々のSAPシステム間でデータを同期するための信頼できる仕組みがありますが、エンタープライズ全体のシステムが記録元システムに直接アクセスできないため、同期エラーが発生した場合にそのエラーを特定して追跡することが困難になる可能性があります。
- この設計では通常、ディレクトリーサービスによって制御される実行時のアクセスと、プロビジョニングサービスによって管理される停止状態のアクセス間での連携は許可されません。以下に例を示します。
- 1時間だけの一時アクセスを付与する必要がある場合はどうなるのか？
- ユーザーが持つアクセスレベルに基づいて認証方法を変更したい場合はどうなるのか？
- SAPに関して中心的な役割を担うユーザーに対して、アクセスが制限されたユーザーより強力な認証が必要な場合はどうなるのか？
このモデルでは、2つの異なるプラットフォームで、2つの異なるアクセスタイプが制御されます。その結果、このようなゼロトラストのユースケースは、通常、複雑で脆弱なオーケストレーションによってのみ一時的に実現できるもので、本来の機能としてはサポートされていません。
より優れた方法があります
Oktaのビジョンは、あらゆる組織があらゆるテクノロジーを安全に使えるようにすることです。つまり、SAPは、それを利用するあらゆる組織にとって重要なコンポーネントである以上、エンタープライズ全体のゼロトラスト戦略に適合する標準化された方法で管理する必要があります。
コンポーネントの概要
Okta Platform
ここでOktaは、エンタープライズ全体を対象としたID管理、Identity Governance、そしてPrivileged Accessサービスを提供します。これにより、アイデンティティがポリシーに従って適切に同期・管理されるようになります。単一のアクセス要求・承認エクスペリエンス、単一のアクセス認定エクスペリエンス、そして最終的に組織向けの単一のコンテキスト対応認証プラットフォームを提供します。
SAP GRC
大規模でコンプライアンス重視のSAP導入では、SAP GRCが重要な役割を果たします。コンプライアンス要件を満たすために求められる、きめ細かい職務分掌チェック機能を提供します。この機能には、SAPが得意とする領域の専門知識が組み込まれています。不適切なアクセスとは、どのようなものか？どのアクセスが、他のどのアクセスと競合するのか？これらの質問は、SAP製品の領域に深く根ざしており、最も適切に答えられるのはSAP自体です。このルールセットこそが、SAP GRC製品で最も価値のあるコンポーネントの1つであると私は考えています。
GRCはこのアーキテクチャにおいて重要な役割を担っていますが、APIおよび管理ツールとして主に機能します。つまり、通常はエンドユーザーや承認者が操作するものではありません。
この図は、推奨される導入パターンにおけるOktaとGRCの役割と責任を大まかに示しています。
一見すると、この戦略には、エンドユーザーと管理者にとって明確なメリットがあります。
- 1つのシステムがエンタープライズ全体のアイデンティティ同期処理をすべて担う。
- エンタープライズ全体で1つの承認プロセス、申請プロセス、監査プロセスが存在する。
- 重要なSAPセキュリティコントロールが維持される。
- 主要な監査プラットフォームは、SAPシステムから最新情報を直接受信するため、仲介によるエラーの可能性がない。
要するに、これは適切な業務に適切なツールを使用するという話です。しかし現在は、「アイデンティティがセキュリティである」という世界で事業を行っており、Oktaでは、アイデンティティツールをセキュリティツールへと変えるIdentity Security Fabricを提供しています。
「コンバージドアイデンティティプラットフォーム」という用語を聞いたことがある方もいるでしょう。これは、業界のリーダーやアナリストによって認識されている概念です。実践に落とし込むと、この概念はSAPの導入環境でのみならず、エンタープライズ全体でのセキュリティにも役立ちます。
先ほど、「停止状態」と「実行時」の2種類のアクセスについて触れました。
- 「停止状態」のアクセスとは、エンタープライズ全体で設定されているユーザー、アカウント、権限、ロールを指します。SAPでは、これはユーザマスタレコードとロールの割り当てに該当します。このアクセスを「停止状態」と呼ぶのは、比較的変動が少なく、SAPの権限チェックで評価されるときに実行時のコンテキストを考慮しないためです。
- 「実行時」のアクセスとは、ユーザーが実際に何かをしようとしたときに発生するものを指します。どのデバイスを使っているか？そのデバイスのポスチャはどのような状態か？どのネットワークからアクセスしているか？振る舞いに何か異常はあるか？どのように認証し、どれくらい前に行われたか？
真の多層防御であるゼロトラスト戦略を実現するには、両方のアクセスタイプが連携して機能する必要があります。ユーザーがアクセス権を持っているだけでは十分ではなく、適切な条件下でのみそのアクセス権を使用しなければなりません。
これらをすべてOktaのような単一のプラットフォームに統合することで、このようなセキュリティレイヤーをスケーラブルな方法で適用できます。その結果、最新のゼロトラストアプローチが実現し、SAP環境が他の重要なインフラストラクチャと同じ厳格さで保護されるようになります。
概要
ここまでお読みいただき、またお時間をいただきましてありがとうございます。この記事での目標は、次の3つの主要な考えを明確にすることでした。
- SAPを使用されるお客様が利用できる、アイデンティティを最新化する機会についての簡単な概要
- 従来型のサイロ化されたアプローチが、真の次世代セキュリティモデルを実現するうえで制約となる理由の分析
- SAPのセキュリティ機能を含む強みを活かしながら、多くの組織が現在構築しているより広範なエンタープライズセキュリティプログラムへSAPを接続する、最新の設計アプローチ
コンバージドアイデンティティプラットフォームが実際に、どのように機能するかについて詳細をご覧になる場合は、最新のウェビナーをこちらでご確認いただけます。
本資料および本資料に含まれる推奨事項は、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネスに関する助言ではありません。本資料は、一般的な情報提供のみを目的としており、最新のセキュリティ、プライバシー、法律の動向、また関連する問題をすべて反映していないことがあります。本資料の利用者は、自身の責任において、自身の弁護士またはその他の専門アドバイザーから法律、セキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本書に記載された推奨事項に依存すべきではありません。本資料に記載された推奨事項を実施した結果生じるいかなる損失または損害に対しても、Oktaは責任を負いません。Oktaは、これらの資料の内容に関して、いかなる表明、保証、またはその他の保証も行いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsをご覧ください。
このブログは、必ずしもOktaの立場、戦略、または見解を表すものではありません。
