- 14 Part I: Oracle Database Security New Features. - For a single application, for example, it’s not uncommon to see base tables in one schema, code in another schema, and metadata or summary data in a third schema. - Isolating these might allow procedural code updates to the code schema to be done without significant (if any) impact on the other schemas. - And, finally, backups may be more frequently done on the data schema as the data probably changes more often than do the procedural and code structures.. - It’s not our intent here to illustrate all the possible ways or possible reasons (barring the security reason) to separate objects into different schemas. - The important point conveyed here is not so much stating the laws on how to organize schemas, but that you should apply a functional and logical organization to your schemas.. - You should understand security implications associated with schemas, as this is critical to ensuring a secure application design and implementation. - It’s important that we point out that no object- level security within a database schema guards itself from itself. - interrelationships and interactions among objects that are necessary for the application to work need to exist without security barriers.. - When this is done, the thinking is usually that the application code will protect the objects from any malicious or malevolent user intent. - It is a bad practice to allow general application users to connect directly to the schema that owns the objects.. - First and foremost, when users are executing within the object owner’s schema, no database security will prevent users from having their way with the data or the data structures (recognizing that fine-grained access controls do provide a safety net here, but the point is still valid). - Turning off the database access security by way of improper design creates a huge risk.. - As you can see in Figure 1-1 for a Sales History (SH) schema, you should not allow application users to connect to the database by way of the SH schema. - If you do, nothing in the database will prevent users from mutilating the data structures and basically having their way with everything contained within the SH. - Obviously, your application would need to provide some sort of security, but even with some security present, allowing user to access the database via the schema is a bad idea.. - User access accounts are the schemas in which end users connect to the database. - These user connections generally occur in one of two ways: The users may be directly connected to the database via a program such as SQL*Plus, or the users may be connected via an application,. - For simplicity, consider only that from the database’s perspective, the end user is connected to a schema.. - From a security perspective, the simplest situation occurs when users have dedicated accounts, because the database applies object-level security and auditing controls at the schema level. - Additionally, you can leverage all the native object-level security controls provided by the database to enforce access controls on a user-by-user basis.. - the database invocation may be done via nested Web services or a federated call, which is unable to convey actual end user identity.. - It has long been argued that you should not allow users to share accounts. - Whether you agree with this or not, shared accounts happen quite frequently, especially when the users share FIGURE 1-1 A security worst-practice is to allow application users to connect directly to the schema that contains the data structures, objects, and code of the application.. - 16 Part I: Oracle Database Security New Features. - The scary aspect of shared accounts is that they are often applied to administrator accounts such as root, SYS, or SYSTEM for the database. - Notionally, and assuming that the accountability and security privileges are maintained, shared accounts are an ideal way to proceed, which is why it is a popular model used today.. - Ideally, individual accounts are created for the DBAs, and the DBA role is granted to each of the individual accounts. - The authorizations and access controls are then based on the privileges assigned to the DBA role, and each DBA’s identity is captured by his or her individual logins.. - Now you know that you should segment schemas and user accounts. - Within user accounts, you need to further divide by function and profile. - One effective way to begin these tasks is to divide the user community into four coarse-level groups. - We’ll use the term user profiles to refer to the categories in which user populations are divided.. - Quite simply, it’s a needed first step to designing security correctly. - You should be able to use this methodology when you build and design your applications. - Read-only users Read-write users. - You don’t need to further define the type of data they will be accessing, except to specify that they should not be able to modify any of it. - Typically, you would use other access control mechanisms to ensure that these users read only the data that they are supposed to.. - You should remember several important security points when building applications for read- only users:. - The security should enforce the fact that the users cannot change the data.. - Users should be confined to the application’s data or only the data they need to access to do their job.. - Users should not be able to change the data objects or perform DDL (such as create or drop tables).. - The second class of users will be the read-write users (Figure 1-3) who not only read the information but also update, enter, delete, and perform other tasks that can change the data.. - 18 Part I: Oracle Database Security New Features. - They should also be prevented from manipulating the data objects themselves.. - The third category of users is the application administrator or application developer, who are included together because the access they require is generally the same. - Configurations and some levels of fine-grained access controls for the application may also be required. - This person’s job is focused around an application, and they should not necessarily have free access to all information in the database.. - Lastly, we want to consider the DBA, As you know, the DBAs are generally concerned about the health and welfare of the database. - Due to the enormous amounts of jobs and activities DBAs need to perform, they generally have superuser access that allows them to access any part of the database and do anything necessary.. - By thinking about the security implications to each of the user profiles, you can immediately decide what risks you will undertake by using dedicated or shared accounts as well as find easy ways to simplify designs and design discussions. - Note that if you decide to share accounts, you will want to seriously consider the suggestions in the database vault chapters (Chapters 4 to 7), which will allow you to share accounts securely and maintain accountability.. - A good way to start with naming is to give the database account/schema the same name or abbreviation for the application module in which it serves. - For example, the sales history objects could be contained in the SH schema, and the order entry objects could be contained in the OE schema.. - Another common practice is to create a new schema for each new version of the application.. - Of course, this makes sense only when the database objects and relationships have been altered as part of the new version. - You will often find the new schema with a version number appended to its name. - For example, later in this book you will see the Application Express (APEX) examples.. - If you dissect the name, you will see the name of the application is Flows, not APEX. - As this version contained code modifications only, it stayed in the FLOWS_030100 schema.. - Consider the following as a start for a potential checklist that you might need to ensure architectural security. - A simple way to start is to consider what happens when the end user clicks something in an application that fetches data from the database.. - If the user is supposed to have only a subset of the privileges for the account to which he or she is connected, what mechanisms are in place to ensure least privilege? It’s better if this security is declarative and enforced inside the database or application server and not programmed within the application code.. - Are you connected directly to the DB through a private or shared connection? If shared, how can you ensure that no information is leaked between connection threads on the application side?. - In the DB, can a privilege escalation path be achieved by exploiting procedures?. - Are connections occurring to the schema that owns the objects? That’s great for development but not so great for runtime, especially if the desired functionality is read-only reporting.. - 20 Part I: Oracle Database Security New Features. - You should now understand the security relevance to the interrelationship among schemas, users, and the data and objects with which they interact. - The rest are addressed with technology, tips, and tricks discussed in the upcoming chapters.. - A few guiding principles serve as a practical way to deal with this challenge. - With all technology—especially security—you need to take a practical approach to implementation. - In this chapter, we established a baseline from which the rest of the book can refer and which you can use to simplify the real issues around building and deploying a secure database application.. - 22 Part I: Oracle Database Security New Features. - ransparent Data Encryption (TDE) is a transparent way to encrypt data in a database.. - It was introduced in Oracle Database 10g. - The database engine automatically encrypts and decrypts data as it reads and writes it from the file system. - In this chapter, we’ll explore how to use TDE and discuss some of the advantages of using it. - First, it’s important to put TDE in perspective with the various other encryption mechanisms Oracle has and continues to offer.. - In its first release, Oracle developed the DBMS_OBFUSCATION_TOOLKIT for release 8i, which gave developers a set of PL/SQL libraries for encrypting data, hashing data, and generating keys in the database. - The second generation of encryption technology came with many improvements over its predecessor in the 10g release of the DBMS_CRYPTO package. - Over a near ten-year period, these packages served as the primary, and really only reasonable method, of encrypting data within the database. - DBMS_CRYPTO uses, caveats, and many useful examples are detailed in Effective Oracle Database 10g Security by Design. - The first difference that you will find is that while DBMS_OBFUCATION_TOOLKIT and DBMS_CRYPTO were features of the database, TDE is a licensed option. - TDE is not simply another way to encrypt data. - the integration with the database engine and ability to implement encryption through SQL Data Definition Language (DDL) make it unique. - TDE is a convenient and practical way to resolve many of the challenges introduced by DBMS_CRYPTO.. - You will hear about several practical uses of TDE, learn details on the mechanics, and see examples of how to get it working for your applications. - To accomplish this, you will see examples based on the storage and use of credit card data. - Credit card data, like all sensitive data, should be protected from disclosure and misuse, because it can cost both cardholders and credit card issuance companies when it’s used in fraudulent transactions. - The following section contains excerpts from the section on encryption from Effective Oracle Database 10g Security By Design. - If you are familiar with the concepts of encryption, such as public and private keys, key management, encryption algorithms, and most importantly when to use encryption and what problems it solves and does not solve, you can skip forward to the next section.. - It dates back thousands of years and can even be traced to the Roman Empire. - At that time, it was common for Julius Caesar, who was acting president and CEO of the Roman Empire, to send messages to his generals in the field. - If the messenger was captured, bribery, persuasive arguments, or torture were ineffective in divulging the contents of the messages.. - It’s important that you understand the basic problem that encryption was designed to solve. - Many security professionals have extensive experience in the network security realm and a strong understanding of cryptography. - This will be your guiding principle for understanding when to use and when not to use encryption within the database.. - That’s good, and it’s called transparency. - You will recall that we posited that transparency was one of the key principles to achieving successful security. - Once the data has been encrypted, it generally needs to be decrypted
Xem thử không khả dụng, vui lòng xem tại trang nguồn hoặc xem
Tóm tắt