Amazing post! I initially found your blog a week or so ago, and I want to subscribe to your RSS feed.
In today’s world, it is quite common for companies to use more than one type of relational database platform to host enterprise applications. If you are an old-time Oracle DBA like me and are asked to administer Microsoft SQL Servers in addition to Oracle databases, the task can be pretty daunting from a SQL Server security perspective. In this blog, I will try to explain the differences and similarities between the Oracle and SQL Server security models.
The difference in security models between the two database platforms stems from the fact that Oracle was not built to run on the Microsoft Windows Operating System (OS). Likewise, SQL was not built to run on operating systems other than Microsoft Windows. While Microsoft has recently announced support for running SQL 2017 on Linux, I have yet to come across a company that has deployed SQL 2017 on Linux in production.
Let us take a step back from security for a minute and understand the primary difference between Oracle and SQL Servers. In the Oracle world, it is quite common to use the term instance and database synonymously. The exceptions being Real Application Clusters (RAC) and the newer Container Database/Pluggable Database (CDB/PDB) scenarios. In a single or stand-alone Oracle instance, there is a one-to-one relationship between instances and databases. Conversely, in the case of RAC, there could be multiple instances associated with a single database. This is not taking into account the ASM instance that Oracle automatically spins up if Oracle Automated Storage Management (ASM) is in use. In the case of CDB/PDB, there is a primary container database, which houses one or more pluggable databases.
For the most part, SQL Server follows the Oracle CDB/PDB model when it comes to database security. SQL Server follows the concept of a SQL Instance running on a server and that instance can contain one or more databases. Each instance contains certain standard databases that are considered to be part of the instance. One such database is called the master database, which contains the instance related metadata. I would consider the master database in the SQL Server to be similar to the container database or CDB in Oracle.
After briefly focusing on the fundamental architectural differences between Oracle and SQL Servers, let us look at the difference in the security models between the two.
Last but not least, I would like to talk about the PUBLIC profile. While it is clearly a profile in SQL Server, when it comes to Oracle it is a different story. For the longest time, I thought about PUBLIC as a role in Oracle. In actuality, PUBLIC is not strictly a role in Oracle. If you refer to the Oracle documentation, Oracle refers to it as a USER GROUP. You will find that PUBLIC does not show up in the DBA_ROLES or any other dynamic view that lists the ROLES in Oracle. Also, it is important to note that any privilege granted to the PUBLIC user group is automatically inherited by all the users defined in the database. In fact, I strongly discourage anyone from granting any type of privilege to the user group PUBLIC in Oracle as it can be a security risk. If you refer to the DISA STIG vulnerability code V-61443, it explicitly states that all privileges granted to PUBLIC should be revoked. In SQL Server, the role public exists at the server or instance level and also at the database level. Figure 3 shows the privileges that are granted by default to the instance level public role. The server level PUBLIC only has the ability to view any database as well as connect to various endpoints. While I do not consider this to be a huge security risk, I will let you be the judge.
SELECT sp.state_desc, sp.permission_name, sp.class_desc, sp.major_id, sp.minor_id, e.name FROM sys.server_permissions AS sp JOIN sys.server_principals AS l ON sp.grantee_principal_id = l.principal_id LEFT JOIN sys.endpoints AS e ON sp.major_id = e.endpoint_id WHERE l.name = 'public';
Once you go from server level PUBLIC role to the database level PUBLIC role, that is where things start to get more interesting. Figure 4 shows the permissions that are automatically granted to the PUBLIC role at the database level. The PUBLIC role at the database level has a lot more privileges than the PUBLIC role at the server level. Since every login in SQL Server inherits the PUBLIC role automatically, please review and ensure that the permissions assigned to the PUBLIC role do not open up a security hole.
SELECT sp.state_desc, sp.permission_name, SCHEMA_NAME(ao.schema_id) AS 'Schema', ao.name FROM sys.database_permissions sp LEFT JOIN sys.all_objects ao ON sp.major_id = ao.object_id JOIN sys.database_principals dp ON sp.grantee_principal_id = dp.principal_id WHERE dp.name = 'public' AND ao.name IS NOT NULL ORDER BY ao.name
While I was able to point out some major differences between Oracle and SQL Server security, this is by no means meant to be an exhaustive list. Regardless of whether you are a seasoned Oracle or SQL Server DBA, STEALTHbits Data Access Governance solutions can assist you in identifying and reporting on all the permissions assigned to users and roles in your databases across the enterprise. You will have the ability to collect, visualize and report on all the SQL Server and Oracle database enterprises as well as AD users & groups, and all files share from a single pane of glass.
To learn more about how STEALTHbits can help with evaluating database permissions, please visit our website: https://www.stealthbits.com/data-access-governance-solution.
Sujith Kumar has over 25 years of professional experience in the IT industry. Sujith has been extensively involved in designing and delivering innovative solutions for the Fortune 500 companies in the United States and across the globe for disaster recovery and high availability preparedness initiatives. Recently after leaving Quest Software/Dell after 19 years of service he was working at Cirro, Inc. focusing on database management and security. His main focus and area of interest is anything data related.
Sujith has a Master of Science in engineering degree from Texas A&M University and a Bachelor of Science in engineering degree from Bangalore University and has published several articles in referred journals and delivered presentations at several events.
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.Read more
Start a Free Stealthbits Trial!
No risk. No obligation.