Oracle® Database Security Guide 11g Release 2 (11.2) Part Number E10574-02 |
|
|
View PDF |
application context
A name-value pair that enables an application to access session information about a user, such as the user ID or other user-specific information, and then securely pass this data to the database.
See also global application context.
application role
A database role that is granted to application users and that is secured by embedding passwords inside the application.
See also secure application role.
certificate
An ITU x.509 v3 standard data structure that securely binds an identify to a public key.
A certificate is created when an entity's public key is signed by a trusted identity, a certificate authority. The certificate ensures that the entity's information is correct, and that the public key belongs to that entity.
A certificate contains the entity's name, identifying information, and public key. It is also likely to contain a serial number, expiration date, and information about the rights, uses, and privileges associated with the certificate. Finally, it contains information about the certificate authority that issued it.
CIDR
The standard notation used for IP addresses. In CIDR notation, an IPv6 subnet is denoted by the subnet prefix and the size in bits of the prefix (in decimal), separated by the slash (/) character. For example, fe80:0000:0217:f2ff::/64
denotes a subnet with addresses fe80:0000:0217:f2ff:0000:0000:0000:0000
through fe80:0000:0217:f2ff:ffff:ffff:ffff:ffff
. The CIDR notation includes support for IPv4 addresses. For example, 192.0.2.1/24
denotes the subnet with addresses 192.0.2.1
through 192.0.2.255
.
CRL
A set of signed data structures that contain a list of revoked certificates. The authenticity and integrity of the CRL is provided by a digital signature appended to it. Usually, the CRL signer is the same entity that signed the issued certificate.
definer's rights procedure
A procedure that executes with the privileges of its owner, not its current user. Definer's rights subprograms are bound to the schema in which they are located. For example, assume that user blake
and user scott
each have a table called dept
in their respective user schemas. If user blake
calls a definer's rights procedure, which is owned by user scott
, to update the dept
table, then this procedure will update the dept
table in the scott
schema because this procedure executes with the privileges of the user who owns (defined) the procedure.
denial-of-service (DoS) attack
An attack that renders a Web site inaccessible or unusable. The denial-of-service attack can occur in many different ways but frequently includes attacks that cause the site to crash, reject connections, or perform too slowly to be usable. DoS attacks come in two forms:
Basic denial-of-service attacks, which require only one or a few computers
Distributed denial-of-service (DDoS) attacks, which require many computers to execute
directly granted role
A role that has been granted directly to the user, as opposed to an indirectly granted role.
forced cleanup
The ability to forcibly cleanup (that is, remove) all audit records from the database. To accomplish this, you set the USE_LAST_ARCH_TIMESTAMP
argument of the DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL
procedure to FALSE
.
See also purge job.
Forwardable Ticket Granting Ticket
A special Kerberos ticket that can be forwarded to proxies, permitting the proxy to obtain additional Kerberos tickets on behalf of the client for proxy authentication.
See also Kerberos ticket.
global application context
A name-value pair that enables application context values to be accessible across database sessions.
See also application context.
indirectly granted role
A role granted to a user through another role that has already been granted to this user. Then you grant the role2
and role3
roles to the role1
role. Roles role2
and role3
are now under role1
. This means psmith
has been indirectly granted the roles role2
and role3
, in addition to the direct grant of role1
. Enabling the direct role1 for psmith enables the indirect roles role2 and role3 for this user as well.
integrity
A guarantee that the contents of a message received were not altered from the contents of the original message sent.
invoker's rights procedures
Procedures that execute with the privileges of the current user, that is, the user who invokes the procedure. These procedures are not bound to a particular schema. They can be run by a variety of users and allow multiple users to manage their own data by using centralized application logic. Invoker's rights procedures are created with the AUTHID
clause in the declaration section of the procedure code.
Kerberos ticket
A temporary set of electronic credentials that verify the identity of a client for a particular service. Also referred to as a service ticket.
last archive timestamp
A timestamp that indicates the timestamp of the last archived audit record. For the database audit trail, this timestamp indicates the last audit record archived. For operating system audit files, it indicates the highest last modified timestamp property of the audit file that was archived. To set this timestamp, you use the DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP
PL/SQL procedure.
See also purge job.
lightweight user session
A user session that contains only information pertinent to the application that the user is logging onto. The lightweight user session does not hold its own database resources, such as transactions and cursors; hence it is considered "lightweight." Lightweight user sessions consume far less system resources than traditional database session. Because lightweight user sessions consume much fewer server resources, a lightweight user session can be dedicated to each end user and can persist for as long as the application deems necessary.
mandatory auditing
Activities that are audited by default, regardless of whether or not auditing was enabled. These activities include connections to the instance with administrator privileges, database startups, and database shutdowns. Oracle Database writes these activities to the operating system audit trail.
namespace
In Oracle Database security, the name of an application context. You create this name in a CREATE CONTEXT
statement.
Oracle Virtual Private Database
A set of features that enables you to create security policies to control database access at the row and column level. Essentially, Oracle Virtual Private Database adds a dynamic WHERE
clause to a SQL statement that is issued against the table, view, or synonym to which an Oracle Virtual Private Database security policy was applied.
In cryptography, a way to strengthen the security of encrypted data. Salt is a random string that is added to the data before it is encrypted, making it more difficult for attackers to steal the data by matching patterns of ciphertext to known ciphertext samples. Salt is often also added to passwords, before the passwords are encrypted, to avoid dictionary attacks, a method that unethical hackers (attackers) use to steal passwords. The encrypted salted values make it difficult for attackers to match the hash value of encrypted passwords (sometimes called verifiers) with their dictionary lists of common password hash values.
secure application role
A database role that is granted to application users, but secured by using an invoker's right stored procedure to retrieve the role password from a database table. A secure application role password is not embedded in the application.
See also application role.
purge job
A database job created by the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB
procedure, which manages the deletion of the audit trail. A database administrator schedules, enables, and disables the purge job. When the purge job becomes active, it deletes audit records from the database audit tables, or it deletes Oracle Database operating system audit files.
See also forced cleanup, last archive timestamp.
role
A named group of related privileges that you grant as a group to users or other roles.
See also indirectly granted role.
separation of duty
Restricting activities only to those users who must perform them. For example, you should not grant the SYSDBA
privilege to any user. Only grant this privilege to administrative users. Separation of duty is required by many compliance policies. See "Guidelines for Securing User Accounts and Privileges" for guidelines on granting privileges to the correct users.