What are "best practices" on the distribution of powers in the Oracle database from the point of view of information security?

Question

Oracle

Can you please tell me what distribution of powers and what logging parameters for different types of accounts correspond to de facto standards or best practices?

If I understand correctly, each administrator must have a personal account for which logging is enabled and access to business data is disabled.
User accounts, if any, should not have access to the application table, and transaction logging, again, should be enabled.

Now administrators in a spherical company log in under dcsdba or sys, and logging is disabled, which does not meet even the standards, but the minimum security requirements.

Answer 1

I think this question is common to all databases. I will sign the ideal option:
- all owners of schemes on the industrial database are blocked. Access under these users is not possible.
- to perform the installation, each database administrator must have his own login, with the rights allowing him to carry out all the necessary operations in these schemes
- logging of the action is configured using standard Oracle aka Audit tools
- all actions of these users are logged there
- the password for the sys account should be in the safe with the main boss and its use should be regulated, because according to the Oracle policy, his actions cannot be pledged, otherwise he will not be able to log into the system in case of unforeseen situations, for example, tablespace overflow for Audit
- from the AUD table, all data should be collected online for monitoring by the security administrator
- successful and unsuccessful commands should stand out as signs to be able to prevent unauthorized access to data
Well, everything seems to be remembered according to PCI DSS

Answer 2

From the point of view of security information, the very first thing to decide is what we are protecting and from whom / from what . Without this, there is no particular sense at all to fence something.
Second : “information security” is always a complex of both technical and organizational measures. One without the other has no meaning.
Here is a list of questions for you:
1) Do you want to protect yourself from DBA? Why then do you keep such a “spherical DBA in a vacuum” that you do not trust? Or do you have administration carried out by a third-party company that you do not trust? Then why such a company? So can “informbezopasnost” start by signing an appropriate agreement with it on liability for possible leaks?
2) Do you want to protect yourself from negligent programmers who steal everything right and left from data and packages on a production basis? The question is correct, but it should be reformulated as follows: are all your programmers such irresponsible schoolchildren, or are there one or two “lead developers” who are sufficiently qualified and responsible?
3) Do you want to protect against incorrect changes/incorrect actions of database users? And also from all sorts of broken/flying external scripts that have a connection to the database?
4) Do you want to protect yourself from evil uncles who sleep and see how to fuck your base and steal all your super-secret data from it?
And now, after the introductory questions, I can share my Best Practice for organizing security (and reliability as well) in Oracle.
* the answer to the 1st question is purely organizational measures
* we are unlearning to keep all the data in the general scheme-garbage.
* we divide schemes into backend and frontend
ones * backend schemes contain business data and packages with business logic for processing them
* backend schemes are divided by tasks and areas of responsibility - each backend scheme has its own responsible lead programmer and no one climbs there without his knowledge.
* front-end schemes do not contain data tables (in general, they simply do not have such a grant as create table). they contain only views and packages that convert the business logic of the "external consumer" into internal logic addressed to backend packages. The actual front-end view and front-end packages, among other things, carry security tasks(such as, for example, not showing, for example, the passport data of physicist clients to the one to whom they should be shown, preventing those who do not need to change certain fields in certain documents, showing only his clients in the front-end view for the manager and not the entire client base, and so on and other ... that is, tasks here can be solved dofiga-dofiga-dofiga, the most important thing is to make a list of these tasks to be solved).
* i.e. pay attention to the separation of "business logic" (backend schemas) and "security logic" (frontend schemas).
* All other users and external scripts go under their own separate login (a user with a grant for connection only). They work only with those front-end objects that are explicitly granted to them. They don’t even know about the structure, organization and existence of something in the backend schemes, which immediately gives + 100% to security and reliability.
I used this organization many times in different places and it always justified itself with a bang.

Answer 3

There is a separate Oracle Database Vault product that just makes it possible to protect business data from DBA, but this is separate money and a separate administrator + probably also Oracle Audit Vault with another administrator ... well, it’s also unlikely to do without separate security officers :). Not everyone can and will want to have such a luxury, but, in general, this is exactly the same technology from privileged users. Presentation PDF