How to conditionally encapsulate fields within ECC 6.0

[Former Member]

I'm interested in strategies to conditionally encapsulate fields within ECC 6.0.

The requirement would be to mask specific fields (e.g. Vendor Name) within a particular data set (e.g. a particular Company Code) by default while allowing those fields to be visible by some users. The key is that we do not want to mask these fields globally, nor do we want them masked for every user. Even more important, we do not want to modify all the transactions and programs where these fields are available.

I know one option is to add custom code at the Domain level of the fields. We're currently investigating this further to see if it will satisfy all our needs and perform well.

I'm looking for any other options we should explore, including 3rd party options.

Thanks,

~Matt

[arpan_paik]

You can use parameter for the same. Like BUK for company code. As this requirement is user specific. Let say user1 should have access to company code 1000. Then in parameter set value for BUK as 1000 for this user and in the role assigned to user set org level value for company code 1000 only.

Arpan

[Former Member]

Hi,

You have a few different options depending on the transactions:

You may be able to use auth object F_KNA1_AEN for customer master transactions

For other transactions you will likely have to look into using inbuilt enhancement points within the transaction to add additional code that validates on an auth object and allows the field to be displayed / edited

For the benefit of Shekar there may be the opportunity to use transaction variants however this isn't always an option depending on the transaction

In this area the most common controls are:

1. Don't give access to the transaction if you can't trust users to use it properly

2. Use a detective control to identify where users have changed things that they shouldn't have.

Finally, using parameter ID's for this purpose generally will not work and should not be considered for security reasons

Edited by: Alex Ayers on Feb 10, 2010 7:02 AM

[Former Member]

Taking the example of the vendor master, i dont think retrcition on F_LFA1_AEN would really help. when a display transaction is used the protected fields are also shown. I understand it is a "no worry' on the complaiance front, but i suppose there could be a valid reason for not allowing users to display something (the operator can shed light on that)

And from what i understand, the object doesnt get checked during the creation of master records too - its primarily to control the changes made on certain fields of the master record.

and it needs a certain amount of effort to understand & check the implications before starting with the filed group customizing

>

> For the benefit of Shekar there may be the opportunity to use transaction variants

thanks, Alex. This need could in all fairness end up with that.... a transaction variant

> 1. Don't give access to the transaction if you can't trust users to use it properly

> 2. Use a detective control to identify where users have changed things that they shouldn't have.

Why do i feel an Auditor posted this????

> Finally, using parameter ID's for this purpose generally will not work and should not be considered for security reasons

100% agree with you

[Former Member]

>

> Taking the example of the vendor master, i dont think retrcition on F_LFA1_AEN would really help. when a display transaction is used the protected fields are also shown. I understand it is a "no worry' on the complaiance front, but i suppose there could be a valid reason for not allowing users to display something (the operator can shed light on that)
> 
> And from what i understand, the object doesnt get checked during the creation of master records too - its primarily to control the changes made on certain fields of the master record.
> and it needs a certain amount of effort to understand & check  the implications before starting with the filed group customizing

I know what you mean, problem in this case is that it's quite a "generic" question and of course different solutions for different transactions.

I was tempted to say "I agree" but as it's in your bugs list I thought I would resist

p.s. I have to admit some guilt about the Auditor tag. I see it as there are lots of ways to stop people doing things. Giving managers very big sticks would be a good, if unpopular one!

[Former Member]

Go to SPRO and search for "Authorization", in required areas. Will help you to see if SAP has provided options to control field level authorization (greying/masking out the field) only to specific users. I remember doing it on FI area but could not recall the exact process.

Gp.

[Former Member]

A few points of clarification. The requirement is to mask certain fields regardless of Change/Display access. An unauthorized user cannot see the contents of the protected fields - period.

These fields, unfortunately, show up in many transaction codes and reports where these same restricted users need and should have access to other fields on the transaction/report. I can't go into a lot of detail on which fields for privacy reasons but take the example of SSN/National ID. That number shows up in many places but is not needed for most HR/T&E people to do most of their jobs. In the HR module, we have the ability to restrict InfoTypes and thus remove the SSN from views in PA20, for example. What we're looking for is a similar concept in the FI area.

Another similar example would be encapsulating credit card numbers to show xxx-xxxx-xxxx-1234. In this example, the CC number is either encapsulated or fully visible depending on the user's authorizations/user group/variant/etc. We need this to go one step further and say that the user can see full credit card info for certain organizational levels only and should see encapsulated CC numbers for all other org levels.

Furthermore, we're looking for a solution that is more robust than just variants. In the CC example, we have a finite number of tcodes/reports to remediate. In my case, I have several fields across different modules that require masking. Though we could tackle each case individually, it would result in a highly complex solution with multiple customizations. I'm trying to understand what more elegant options might be out there.

The Domain exit option allows me to attack only the domains of the relevant fields and leverage that code across all transactions/reports. Again, we are still investigating the details and performance impacts of this solution, but it is the type of answer I'm looking for.

[Former Member]

> ... but take the example of SSN/National ID. That number shows up in many places...

This is a security design error beyond the boundaries of SAP, perhaps even any other system on earth...

> Another similar example would be encapsulating credit card numbers to show xxx-xxxx-xxxx-1234. In this example, the CC number is either encapsulated or fully visible depending on the user's authorizations/user group/variant/etc. We need this to go one step further and say that the user can see full credit card info for certain organizational levels only and should see encapsulated CC numbers for all other org levels.

This one is possible in a combination of config and authorizations to both view the data org. dependently and if it can be viewed then also decrypt it (so it is a mutually inclusive intersection of the authority which permits both, otherwise nothing).

But... the call stacks of some encryption / decrpytion options are "owned" by SAP, and if something is decryptable then you need to consider that in the system somewhere there is a function to decrypt it again. You will not be able to use it for every single user-case you can think of. Legal requirements would be a stronger argument...

Cheers,

Julius

[Former Member]

Assume the requirement would be met if the solution protects the typical "end user" case via transaction codes and reports. We can tackle admin support and superuser level restrictions separately.

Can you elaborate on how you would accomplish this restriction?

[Former Member]

For your specific example, I would use the credit card encryption functionality which SAP offers. There are plenty of docs here on SDN, help.sap.com and the SMP on it. If you have a webshop then it is even a legal requirement, so it is not an option for you really (unless you are willing to take on the risk of liability which has as much imagination as the internet itself.. :-).

Where it gets tricky is in the area of IDocs (if you are using them to transfer CC data). For this it is best to get some expert help upfront before trying to figure it out on your own the first time.

Cheers,

Julius

[Former Member]

I've been through the same exercise over the last couple of years. Whichever way you look at it, you are going to need to use a variety of techniques to meet these changes to standard SAP. There were 100+ transactions that were in scope, approx 50 required modification. When you are chopping about standard SAP, elegant can be hard to achieve. Where you use EP's or copies of tx you can unify it under a common set of auth objects and logic.

We settled on a variety of options:

1. Use enhancement points to add in additional authorisation checks for the ability to see certain fields (no measurable performance impact)

2. Standard auth concept

3. Create copies of standard transactions

4. Transaction variants (avoided the use where possible as do not really give variable control over field display)

5. Moved sensitive reporting to BI

1, 3 & 5 were most commonly used, followed by 2 and then 4.

What I would say is that much of this should only be considered if there is a cast iron legal requirement to do so. Having it as a "nice to have" or operational requirement gives a dubious benefit case.

[Former Member]

If you encrypt the data at it's source and don't save it redundantly, then the user has to pass the API to decrypt it again. That is easier to control (the ones which you do use) than all the ones which you don't.

You can also be more pick and choosy about which transaction you give the users that way.

My 2 cents,

Julius

[Former Member]

Good for credit card info, not sure how easy it would be to extend similar for another element - take price for example. What do you reckon?

[Former Member]

My vendors publish their prices on grocery store shelves. I have difficulty enough as it is comparing the prices...

It is like salary data as well. For some it is the holy grail of information. For others it is published in the financial reports. If there isn't a compelling legal requirement or infrastructural security risk, we have to use what the application layer has to offer and make people sign contracts.

Cheers,

Julius

[Former Member]

In this case we have very strict legal requirements to restrict access to this data to very specific user sets. In reality I'm not even concerned with Credit Card or even SSN (they have a pretty tight HR security model already in place). Those were examples for lack of the ability to give you guys my real scenario. I'm afraid Alex may have nailed it unless I can find out more about the encryption options.

Do you use a 3rd party package for the logic or are those hooks available within standard SAP. If they're available, are they available for all data fields or just certain ones?

Thanks for all the feedback, gents. Much appreciated.

[Former Member]

> Those were examples for lack of the ability to give you guys my real scenario.

These are professional public forums.

Please providing appropriate details of your requirement if you expect us to have a reasonable chance of helping you without guess-work.

There are many things to consider... and where there is no complete API (Application Program Interface) then there also is no complete answer!

Some recommended reading before you proceed further:

http://forums.sdn.sap.com/click.jspa?searchID=38541605&messageID=4675719

and

http://forums.sdn.sap.com/click.jspa?searchID=38541624&messageID=7947281

Cheers,

Julius

Edited by: Julius Bussche on Feb 12, 2010 12:23 AM

Thread unlocked again

[Former Member]

ps: Particularly the comments in the first thread about package interfaces will be usefull for you! However.. if you have prior concocted a myriad of user exits then you will understand why the syntax checks are optionally only a warning, and not an error.

I would specifically be interested in your opinion on this aspect and how your system is "contributing" to it. Ofcourse if you provide the package name and whether you have used the switch framework in ECC 6.0 for these business functions (in this case, you might not even need to mention the name...) then it would help.

Cheers,

Julius

[Former Member]

I want to add some clarity to my question to avoid confusion and ensure I'm not misleading anyone.

The fields I need to mask are of various sorts. Some are indexed, some are not. Some belong to tables which are buffered, and some do not. None of the fields are keyed. They are all text based - numbers are not an issue for us. The requirement involves fields that provide a certain type of descriptive information that could take the form of an abbreviation, a full sentence, a phrase, or just a single word. The key is that we are only concerned about the contents of these fields within a very specific organizational cross section of the client's data. For other areas the fields could say whatever they want and anyone with a functional reason to run that tcode or report could see the text.

I understand that for each individual data element there may be a pretty straightforward option to satisfy my requirement (create a variant, add some logic to an enhancement point, copy the tcodes and create custom versions, etc). The issue I have is the sheer number and varying type of fields I need to protect. If we set out to modify each tcode, report, variant, etc, we run the risk of a model that is more complex and costly to maintain than the cost to reorganize the business and segregate the specific org units in their entirety.

So, simply stated, I'm seeking to understand if there is a way to protect MANY text based fields across an entire ECC 6.0 system (running SQL Server for the DB) without patching together MANY different solutions. I haven't worked much with DB encryption (SAP used to frown on it but I understand it is becoming more acceptible) or that type of solution so perhaps that's an angle?

[Former Member]

> The issue I have is the sheer number and varying type of fields I need to protect.

Exactly that is what the package concept sets out to do --> providing interfaces to the packaged data. You can then control the interface access beyond its (consistently used) boundardy, also to encrypt and decrypt if you wish, or extend the tables.

However the more self-constructed mechanisms for simmulating this there are in circulation, the less likely it is to see this warning switched to an error.

From my observations, SAP has placed an increased awareness on the difference between an OLTP (transactional) and OLAP (analysis) based systems (they even bought whole companies for it!) and at the end of the day will hopefully not go looking for the very last exit or modification made in 46C which is still expected to work in 7.30.

This is the best generic advice I have to offer (and support for it is needed as well!)

If you have specific requirements (e.g. passwords) then there already are technology and industry specific solutions. Some may even be "package concept complaint" and their packages could (possibly) be switched earlier than others. For example, BC-SEC is reasonably complete.

Cheers,

Julius

[Former Member]

There are various approaches to your problem already, which I am not comfortable with (since I am the poor Basis person that has to deal with clones after support packages + during and after upgrades) - so I will not follow Alex' recommendation of cloning SAP transactions and/or programs. The reasons are simple: the original will be changed/enhanced/completely redesigned via notes/ patches/ upgrades. Your clone will not. You will have to find that thing manually (unless you can afford to let Panaya do the work for you), adapt it to the SAP-functionality manually (if even possible) and you're going to pay for it (repeatedly for ever patch/upgrade!) and you would be amazed at the figures that appear on the bills. I can tell: I am in midst-upgrade and currently dealing with 350+ clones ...

Have you considered doing a complete own developement either in a portal-layer on top of your ECC or in ECC itself that is mainly a surface for the users to work with - you could set the rules for display/data fetching etc. yourself. The entire thing could be properly encapsulated and tons of BAPI's would secure data transfer from/to backend. The maintenance would be much easier and less expensive than modification/cloning etc. plus (!!) you would keep the system maintainable (which honestly I do not see in Alex' suggestions (no offense meant, Alex)).

Just a thought, yes?

Nice weekend, all.

Edited by: Mylène Dorias on Feb 12, 2010 3:10 PM

[Former Member]

>The maintenance would be much easier and less expensive than modification/cloning etc. plus (!!) you would keep the system >maintainable (which honestly I do not see in Alex' suggestions (no offense meant, Alex)).
>

None taken.

Cloning of standard tx is not something that I would ever recommend lightly.

In our situation we had a legal requirement that could not be achieved any other way in the cases where cloning & change were used. We spoke in depth with various parties (including SAP) and the options were not compelling in this situation. Copying & changing standard is "last resort".