71 lines
2.5 KiB
Markdown
71 lines
2.5 KiB
Markdown
# PoC and Lab Guides
|
|
|
|
Use these structures for practical proof-of-concept work.
|
|
|
|
## PoC Template
|
|
|
|
1. Objective: define the risk or audit objective.
|
|
2. Scope: databases, schemas, tables, users, applications, and network paths.
|
|
3. Prerequisites: versions, options, privileges, licenses, connectivity, backups, and rollback.
|
|
4. Baseline: capture current performance, privileges, audit volume, and operational process.
|
|
5. Configuration: implement the smallest meaningful control.
|
|
6. Tests: positive, negative, performance, failover, audit, and rollback cases.
|
|
7. Evidence: screenshots, SQL output, reports, logs, diagrams, and decision record.
|
|
8. Acceptance criteria: security outcome, application impact, operational readiness, and support model.
|
|
|
|
## Example TDE Lab Skeleton
|
|
|
|
Adapt syntax to the target Oracle version and wallet or OKV model.
|
|
|
|
```sql
|
|
-- Inventory candidate tablespaces.
|
|
SELECT tablespace_name, encrypted FROM dba_tablespaces ORDER BY tablespace_name;
|
|
|
|
-- Check wallet status.
|
|
SELECT wrl_type, status, wallet_type FROM v$encryption_wallet;
|
|
|
|
-- Example only: encrypt a test tablespace after backup and rollback planning.
|
|
ALTER TABLESPACE test_data ENCRYPTION ONLINE USING 'AES256' ENCRYPT;
|
|
|
|
-- Validate encrypted state.
|
|
SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE tablespace_name = 'TEST_DATA';
|
|
```
|
|
|
|
Acceptance tests:
|
|
|
|
- Application read/write flows still pass.
|
|
- Backup and restore procedure is validated.
|
|
- Wallet or OKV outage scenario is understood.
|
|
- Key rotation procedure is documented and tested in non-production first.
|
|
|
|
## Example Database Vault PoC
|
|
|
|
Test scenario:
|
|
|
|
- Create a realm around a sensitive application schema.
|
|
- Authorize the application owner and break-glass role.
|
|
- Attempt access as a powerful DBA account.
|
|
- Confirm blocked access is audited and operational tasks still work through approved paths.
|
|
|
|
Evidence:
|
|
|
|
- Realm definition.
|
|
- Authorized users and roles.
|
|
- Failed privileged access test.
|
|
- Successful approved access test.
|
|
- Emergency access procedure.
|
|
|
|
## Example AVDF or Data Safe Audit PoC
|
|
|
|
Test scenario:
|
|
|
|
- Define high-risk events: privileged logon, failed logon, DDL, access to sensitive tables, grants, role changes, and policy changes.
|
|
- Generate test activity.
|
|
- Confirm collection, alerting, report generation, retention, and SIEM forwarding if required.
|
|
|
|
Acceptance criteria:
|
|
|
|
- Important events are captured with user, source, object, action, and timestamp.
|
|
- Noise is manageable.
|
|
- Reports answer audit questions without manual log stitching.
|