監査人から、本番環境でSAP_ALL相当の権限を持つユーザーが六名いると指摘された。うち二名は保守ベンダーの要員である。情報システム部門の答えは決まっている。夜間バッチが落ちたときに、この権限がないと復旧できない。経理の答えも決まっている。決算三日目に伝票が突き抜けたとき、待っていたら締まらない。両方とも正しい。 正しいがゆえに、指摘は毎年繰り返され、毎年「運用でカバーしています」と回答され、翌年また同じ行が指摘事項に載る。
抜け出す道は、権限の絞り方をもう一段工夫することではない。強い権限が要る場面は消えないという前提を先に認めて、渡し方と返し方を工程に変える。 恒久付与をやめられるかどうかは、設計の巧拙ではなく、この工程を回し続けられるかで決まる。
論点は権限の設計ではなく、貸出の工程である
EAMの用語は、そのまま運用設計の骨格になっている。SAPの構成ガイドは、Firefighterを緊急アクセスを必要とするユーザー、Firefighter IDを昇格した権限を持つユーザーID、Firefightingを緊急時にFirefighter IDを使って作業する行為と定義する。そして残る二つが要である。Ownerは 「the user responsible for a Firefighter ID and the assignment of controllers and Firefighters」、Controllerは 「the user who reviews and approves (if required) the log files generated from firefighting activities」 とされる。
貸す人と、後から点検する人が、最初から別のロールとして定義されている。 実際、SAP Access Control 12.0では所有者・点検者の区分がID方式とロール方式それぞれに用意され、Firefighter ID Owner、Firefighter ID Controller、Firefighter Role Owner、Firefighter Role Controllerの四つが並ぶ。多くの日本企業がここでつまずくのは、OwnerとControllerを同じ情報システム部門の課長に兼ねさせてしまうことである。自分が貸した権限の使われ方を自分で点検する構造は、IPAが求める分離をそのまま外している。 Controllerは業務側に置く。会計伝票に触れる権限なら経理部門の管理職、購買なら購買部門の管理職である。SAPの運用ガイドも、管理者・業務プロセスオーナー・Controllerが、Firefighterの実施した緊急アクセスの活動をレビューする定型のプロセスを持つ必要があると明記している。
なお配布されているロールは雛形であり、ドキュメントは 「The delivered roles are sample roles. You must copy them into your own namespace」 としている。標準のまま本番に載せる想定にはなっていない。
ID方式とロール方式で、残る証跡が変わる
EAMには二つの方式があり、パラメータ4000で切り替える。値1がID方式、値2がロール方式で、「You can use only one application type at a time.」、つまり同時併用はできない。この選択は運用の見た目より、残る証跡の性質を変える。
| ID方式（ID-Based） | ロール方式（Role-Based） | |
|---|---|---|
| 渡し方 | 専用のFirefighter IDを利用者に割り当て、EAMの画面からそのIDでログオンする | 対象システム側に作った緊急用ロールを、利用者のIDに割り当てる |
| 監査証跡での見え方 | 変更履歴の実行者は共有のFirefighter IDになる | 実行者は本人のユーザーIDのまま残る |
| 誰がやったかの特定 | EAMのログと突き合わせて初めて分かる | 通常の変更履歴だけで追える |
| 向いている場面 | 保守ベンダーなど、常設のIDを持たない相手に貸す場合 | 社内の要員に、限られた時間だけ権限を足す場合 |
ID方式を選ぶと、CDHDRやCDPOSに残る変更者は共有IDになる。 誰が実行したかはEAMのログを突き合わせて初めて確定するので、後述するログ同期が止まっていた場合、変更の実行者を特定できない期間が生まれる。ロール方式なら実行者は本人のIDのまま残るため、この紐付けが切れない。保守ベンダーに貸す用途ではID方式が現実的だが、社内要員に対してまでID方式で統一する必要はない。貸す相手が社内か社外かで方式を分けられないという制約（同時併用不可）は、設計の初期に効く。
起動に使うトランザクションは、集中運用ならGRAC_EAM、プラグイン側の分散運用なら/GRCPI/GRIA_EAMである。GRAC_SPMも動くが、SAPのガイドはこれを後方互換のために残しているものと位置づけている。SPMは旧称のSuperuser Privilege Managementに由来し、2012年にEmergency Access Managementへ改称された。古い手順書がGRAC_SPMを正として書いていることがある。
ログを取っていることと、証跡が残っていることは別である
ここが実務で最も抜ける。
EAMが集めるログは六種類で、SAPのユーザーガイドは種別ごとに取得元を明記している。Transaction Logはトランザクションの実行をSTADから、Document Objects Change LogはCDPOSとCDHDRの変更文書から、Table Data Change LogはSE16、SE16N、SE17、SM30、SM31などによるテーブル変更から、System LogはSM21のDebug & Replaceの情報から、Security Audit LogはSM20から、OS Command LogはSM49からそれぞれ取得する。
Debug & Replaceは独立したログではなく、System Logの中身である。 そしてTable Data Change Logが別立てになっていることが重要で、ここが落ちるとSE16Nから直接テーブルを書き換えるという最も危険な経路の記録が消える。手順書のログ一覧が五種類以下になっている場合、たいていこの二点のどちらかを取り違えている。
問題は保持期間である。SAPのドキュメントは、STADの統計ファイルについて 「The total number of files is usually restricted to 48 (profile parameters stat/max_files or stat/as_max_files).」 とし、「This data is therefore stored for two days before it is overwritten.」 と書く。既定でおよそ二日で上書きされる。一方、Firefighterのログ同期ジョブについてSAPの管理ガイドが推奨する頻度は日次である。二日で消えるデータを、日次で拾いに行く設計になっている。 余裕は一日しかない。
したがって、連休を挟んでジョブが止まった、GRCとプラグインの接続が切れていた、といった事象が起きると、その期間の実行トランザクションは後から復元できない。権限保有者の一覧をいくら綺麗に保っても、証跡が欠けた期間は取り戻せない。 監視すべき対象は、権限の棚卸し結果ではなくジョブの実行結果である。ここを月次の統制として文書化しておくと、監査での説明が一段楽になる（J-SOX財務報告内部統制：3点セットを形骸化させない更新運用の実務）。
テーブル変更ログにも前提がある。ログの取得はテーブル単位の設定で、SAPは 「If logging is activated, access to the database table slows down accordingly.」 とし、多数のテーブルで有効にすればログテーブルでロックが発生し得ることも記している。性能と証跡のトレードオフが公式に書かれている以上、全テーブルで有効にする運用は現実的でない。会計に効くテーブルを列挙して、そこだけ有効にする判断が要る。 取得済みの内容はSCU3、いわゆるテーブル履歴で確認できる。
セキュリティ監査ログにも落とし穴がある。SAPのS/4HANAセキュリティガイドは、セキュリティ監査ログが新規システムでは既定で有効になっているとしたうえで、既存システムについては、少なくとも新規システムで既定として記録される事象に関してログを有効にすることを推奨している。裏返せば、稼働から年数の経ったシステムでは既定で無効のままである可能性がある。 設定はSAP NetWeaver 7.50以降でRSAU_CONFIGが導入されており、古い手順書のSM19から更新されているかを確認する（SAPの権限設計とSoD（職務分掌）｜内部統制を仕組みで担保する）。
事後レビューが形骸化する理由は、件数ではなく理由コードにある
貸出の工程を作った会社が、半年後にぶつかるのがレビューの形骸化である。毎月Controllerに何十件ものログが回り、全部に承認が押される。読んでいないから押せる。
原因は件数ではなく、すべての貸出が「緊急対応」という同じ名前で括られていることにある。 理由を自由記述にしている会社では、備考欄が「障害対応のため」「決算作業のため」で埋まる。この粒度では、どれを重点的に見るべきかをControllerが判断できない。
理由コードを設計する。EAMには理由コードと活動を突き合わせるレポート（Reason Code and Activity Report）が用意されており、コードを分けておくと集計の意味が変わる。分け方の軸は、その事象が再発するかどうかである。深夜バッチの異常終了、インターフェースの連携エラー、マスタの不整合による転記エラー、期間クローズ後の修正、外部監査対応の照会。この五つに分けるだけで、四半期の集計から「毎回出てくるもの」が浮かび上がる。
浮かび上がったものは、緊急ではない。決算のたびに必ず使われる権限は、恒常的な業務要件であって緊急時アクセスではない。 それは通常のロールに正しく組み込んだうえで職務分掌の抵触を検証すべきものであり、緊急枠に置き続けると、統制の抜け道として定着する。逆に、年に一度も使われない理由コードがあれば、その貸出枠自体を廃止する。理由コードは、レビューを楽にするための道具であると同時に、緊急枠を痩せさせるための道具である。
四半期ごとの棚卸しにはFirefighter ID Reviewを使う。貸出枠は放っておくと増える一方で、退職者や異動者に紐づいたまま残る。
決めるのは三つ
第一に、OwnerとControllerを別の部門に置く。 貸す人と点検する人を同じ情報システム部門に置くと、実行者が自分の作業を点検する構造になる。Controllerは会計伝票なら経理、購買なら購買と、業務側の管理職に持たせる。IPAの「組織における内部不正防止ガイドライン」第5版がシステム管理者のログをシステム管理者以外が確認しなければならないとしているのは、この分離のことである。兼務のまま件数を増やしても、承認は形式化する。
第二に、監視の対象を、権限の一覧からログ同期ジョブに移す。 EAMが集める六種のログのうちTransaction Logの取得元であるSTADは、統計ファイルが既定でおよそ48本、二日で上書きされる。SAPが推奨する同期頻度は日次で、余裕は一日しかない。ジョブが止まった期間の証跡は後から取り戻せないため、死活監視と失敗時の通知先を月次統制として文書化する。通知先を個人名にしない。 テーブル変更ログは性能とのトレードオフがあるため対象テーブルを絞り、セキュリティ監査ログは稼働年数の長いシステムで既定無効のままになっていないかを確認する。
第三に、理由コードを設計して、四半期ごとに「毎回出てくるもの」を緊急枠から出す。 深夜バッチ異常終了、連携エラー、マスタ不整合、期間クローズ後修正、監査照会のように再発性で分ける。毎月使われる権限は緊急時アクセスではなく恒常的な業務要件であり、通常のロールに組み込んだうえで職務分掌の抵触を検証し直す。緊急枠に残し続けると、そこが統制の抜け道として定着する。
そのうえで方式を選ぶ。ID方式とロール方式は同時併用できないため、社外要員への貸出を主とするならID方式、社内要員が中心ならロール方式が追いやすい。ID方式では変更履歴の実行者が共有IDになり、誰がやったかの確定がEAMのログに依存する。 依存する以上、その一本が切れたときの影響は大きい。二つ目の決めごとに戻ってくる。
