Search Results disable_protection_column




Overview

SYS.DBMS_TSDP_PROTECT is the Transparent Sensitive Data Protection (TSDP) policy management package delivered as part of the Oracle Database security stack. In the Oracle E-Business Suite 12.1.1 and 12.2.2 environments, this package resides in the SYS schema and is exposed to the APPS schema through standard database privileges. It provides the PL/SQL interface through which DBAs and security administrators declare, associate, enable, and disable protection policies against sensitive columns without hand-coding the individual security features themselves.

The package is a unifying control layer: rather than configuring Oracle Data Redaction, Virtual Private Database (VPD), Fine-Grained Auditing (FGA), Column Encryption, or Unified Audit separately for each column, an administrator defines a single TSDP policy and lets the database engine propagate that policy to every column that matches the declared datatype, length, schema, or parent-table conditions. In an EBS context this is significant because EBS instances typically contain hundreds of sensitive columns (for example, salary, national identifiers, and bank account numbers) scattered across many schemas, and TSDP allows these to be protected consistently and as a group.

The documentation for this object defines the package as AUTHID CURRENT_USER, meaning execution privileges are evaluated against the invoking user, and it declares the security-feature constants (REDACT, UNIFIED_AUDIT, VPD, COLUMN_ENCRYPTION, FGA) plus the maximum parameter size of 4000 characters.

Key Procedures and Functions

The package exposes eleven documented procedures, which fall into four functional groups.

  • ADD_POLICY — Creates a new protection policy, binding a policy name to a security feature and supplying the enable options and apply conditions that determine which columns the policy covers.
  • ALTER_POLICY — Modifies an existing policy's enable options or apply conditions without recreating it.
  • DROP_POLICY — Removes a protection policy definition from the data dictionary.
  • ASSOCIATE_POLICY — Links a defined policy to a specific sensitivity type or column, establishing the relationship that drives enforcement.
  • ENABLE_PROTECTION_SOURCE / DISABLE_PROTECTION_SOURCE — Turn protection on or off for an entire protection source, allowing bulk activation at the source level.
  • ENABLE_PROTECTION_COLUMN / DISABLE_PROTECTION_COLUMN — Turn protection on or off for an individual column, offering granular control when a source-wide setting is too broad.
  • ENABLE_PROTECTION_TYPE / DISABLE_PROTECTION_TYPE — Turn protection on or off for a sensitivity type, enabling policy enforcement across every column classified to that type.

The parameter-level comments in the source indicate that ADD_POLICY accepts a policy name (subject to the Oracle identifier length limit), a security feature constant, an associative array of enable options indexed by feature name, and a condition array keyed by PLS_INTEGER whose permissible properties include DATATYPE, LENGTH, PARENT_SCHEMA, and PARENT_TABLE.

Tables Accessed

The ETRM metadata for this package records no APPS-synonym table references; the package operates entirely on SYS-owned TSDP data dictionary tables and internal metadata structures created and maintained by the database. Policy definitions, policy associations, enabled protection sources, columns, and types are persisted automatically when the procedures above are invoked. Because these objects are not exposed through EBS synonyms, EBS application code does not query them directly.

Usage Notes

Within EBS 12.1.1 and 12.2.2, this package is not typically invoked from a standard EBS form or concurrent program. It is used by database administrators executing ad hoc scripts, by database security tooling, or by custom PL/SQL that must programmatically register and enable TSDP policies. The package is referenced by one other package per the documented metadata, confirming it is intended as a lower-level building block. Administrators should invoke it as a privileged user, verify that the target sensitivity types and columns exist, and exercise care when enabling protection across a whole source, since that affects every associated column at once.