Initial Oracle Deep Data Security lab kit
Some checks failed
Repo Quality / structure (push) Has been cancelled
Terraform Validate / validate (push) Has been cancelled

This commit is contained in:
Rodrigo Pace
2026-05-08 12:08:05 -03:00
commit 5cd8752a90
88 changed files with 2189 additions and 0 deletions

46
docs/architecture.md Normal file
View File

@@ -0,0 +1,46 @@
# Arquitetura Do Lab
## Objetivo
Criar uma fundação OCI segura e repetível para demonstrar Oracle Deep Data Security em workloads de AI, analytics e aplicações corporativas.
## Desenho Lógico
```mermaid
flowchart LR
User["Usuário Final / Analista"] --> App["Aplicação ou Agente AI"]
App --> PE["Private Endpoint do Banco"]
BI["Ferramenta BI / SQL Client"] --> PE
PE --> ADB["Oracle AI Database / Autonomous Database"]
ADB --> Policies["Deep Data Security Data Grants"]
ADB --> Audit["Unified Audit / Evidências"]
KMS["OCI Vault / KMS Opcional"] --> ADB
Admin["Operação DBA"] --> Bastion["Bastion Opcional"]
Bastion --> PE
```
## Componentes
| Camada | Componente | Função |
| --- | --- | --- |
| Rede | VCN, private subnet, NSGs | Isolar banco e aplicações por fluxo permitido. |
| Banco | Autonomous Database privado | Executar schemas, policies e testes do lab. |
| Segurança | Deep Data Security | Aplicar autorização por usuário, role e contexto. |
| Chaves | OCI Vault opcional | Permitir chave gerenciada pelo cliente quando necessário. |
| Operação | Bastion compute opcional | Acesso administrativo controlado quando o cliente exigir. |
| Evidência | SQL output, logs e screenshots | Apoiar demonstração e validação técnica. |
## Princípios De Segurança
- Banco sem exposição pública.
- Acesso por subnet privada e NSG.
- mTLS obrigatório.
- Secrets mantidos fora do Git.
- Privilégios mínimos para recursos OCI.
- Políticas de dados versionadas em SQL.
- Controles preventivos primeiro; auditoria como evidência e investigação.
## O Que Fica Fora Do Terraform
Terraform provisiona infraestrutura. A configuração fina de usuários, data roles, data grants e dados de teste fica nos diretórios `scenarios/`, para que cada lab seja instalado e resetado sem recriar a OCI inteira.

View File

@@ -0,0 +1,28 @@
# Guia De Demo Executiva
## Duração
30 a 45 minutos.
## Mensagem Principal
Deep Data Security protege o dado na origem. Mesmo que um agente AI, aplicação vibe-coded, BI ou SQL dinâmico tente consultar mais do que deveria, o banco aplica autorização por usuário final, role e contexto.
## Roteiro
1. Mostre o problema: uma aplicação ou agente usa uma conexão poderosa.
2. Execute uma pergunta perigosa: "liste todos os salários e documentos".
3. Mostre o resultado com excesso de dados no baseline, quando aplicável.
4. Ative ou explique os data grants.
5. Execute a mesma consulta como usuário limitado.
6. Mostre que linhas e colunas não autorizadas são filtradas ou mascaradas.
7. Mostre a visão de gerente ou RH com maior privilégio.
8. Feche com evidência de auditoria e governança.
## Frases De Valor
- "A autorização acompanha o usuário, não apenas a aplicação."
- "O controle fica no banco, onde o dado reside."
- "Aplicações, agentes e BI passam a respeitar a mesma fronteira de acesso."
- "A política é declarativa, versionável e auditável."

23
docs/git-push.md Normal file
View File

@@ -0,0 +1,23 @@
# Comandos Git Para Publicar
Execute a partir do diretório que contém `oracle-deep-data-security-lab`.
```bash
cd oracle-deep-data-security-lab
git init
git checkout -b main
git add .
git commit -m "Initial Oracle Deep Data Security lab kit"
git remote add origin <URL_DO_SEU_REPOSITORIO>
git push -u origin main
```
Para evoluir:
```bash
git checkout -b feature/scenario-05-rag-vector-access
git add .
git commit -m "Add RAG vector access scenario"
git push -u origin feature/scenario-05-rag-vector-access
```

59
docs/lab-execution.md Normal file
View File

@@ -0,0 +1,59 @@
# Execução Dos Labs
## 1. Preparar Ambiente
```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\bootstrap.ps1
```
## 2. Configurar Terraform
```powershell
Copy-Item terraform/envs/demo/terraform.tfvars.example terraform/envs/demo/terraform.tfvars
notepad terraform/envs/demo/terraform.tfvars
```
Preencha:
- `tenancy_ocid`
- `compartment_ocid`
- `user_ocid`
- `fingerprint`
- `private_key_path`
- `region`
- `adb_admin_password`
## 3. Validar Terraform
```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\validate-terraform.ps1
```
## 4. Aplicar Infraestrutura
```powershell
Set-Location terraform/envs/demo
terraform init
terraform plan -out tfplan
terraform apply tfplan
```
## 5. Executar Cenário
```powershell
Set-Location ../..
powershell -ExecutionPolicy Bypass -File .\scripts\run-scenario.ps1 -Scenario 01-ai-prompt-injection -ConnectString "<connect_string>"
```
## 6. Resetar Cenário
```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\reset-scenario.ps1 -Scenario 01-ai-prompt-injection -ConnectString "<connect_string>"
```
## 7. Destruir Ambiente
```powershell
Set-Location terraform/envs/demo
terraform destroy
```

26
docs/scenarios.md Normal file
View File

@@ -0,0 +1,26 @@
# Catálogo De Cenários
## 01 - AI Prompt Injection
Mostra um agente AI tentando gerar SQL amplo demais. Deep Data Security limita o retorno ao contexto do usuário final.
## 02 - Shared App Account
Mostra o problema de uma conta técnica de aplicação usada por vários usuários. O controle relevante passa a ser o end user/contexto, não apenas a conta do pool.
## 03 - PII Row/Column/Cell
Mostra controle de acesso por linha, coluna e célula. Funcionário vê seu registro; gerente vê time com SSN oculto; RH vê atributos sensíveis.
## 04 - View Bypass / MAC
Mostra como uma view pode virar caminho alternativo de acesso e como `USE DATA GRANTS ONLY` força a política da tabela base.
## Próximos Cenários Sugeridos
- RAG/vector search com documentos classificados.
- BI por região, filial e centro de custo.
- Escrita controlada com `UPDATE`, `INSERT` e `DELETE`.
- Complemento com Database Vault para bloquear DBA.
- Auditoria com Data Safe ou AVDF.

29
docs/security-model.md Normal file
View File

@@ -0,0 +1,29 @@
# Modelo De Segurança
## Controles Obrigatórios
- Banco em endpoint privado.
- NSG dedicado para banco.
- mTLS obrigatório.
- Senhas, API keys, wallets e `.tfvars` fora do Git.
- Usuários de demo sem privilégios administrativos.
- SQL de reset por cenário.
## Controles Recomendados
- OCI Vault com chave gerenciada pelo cliente.
- Data Safe para assessment, discovery, masking e activity auditing quando suportado.
- Logging e retenção de eventos OCI.
- Integração com SIEM para labs avançados.
- Database Vault para demonstrar bloqueio de DBA em schemas sensíveis.
## Controles Opcionais
- Bastion compute com IP público restrito.
- Oracle Key Vault para cenários híbridos ou multicloud.
- AVDF para auditoria centralizada e Database Firewall em ambientes on-premises ou Exadata.
## Observações Importantes
Deep Data Security controla autorização em tempo de execução. Ele não substitui TDE, masking de ambientes não produtivos, Database Vault, Data Safe, AVDF ou governança de chaves. Em uma arquitetura de cliente, esses controles devem ser combinados conforme o risco.

38
docs/troubleshooting.md Normal file
View File

@@ -0,0 +1,38 @@
# Troubleshooting
## Terraform Plan Falha Por Autenticação
Verifique:
- OCIDs corretos.
- Região correta.
- Fingerprint da API key.
- Caminho da chave privada.
- Permissões IAM para criar recursos.
## Autonomous Database Não Aceita Versão Informada
Remova ou ajuste `adb_db_version` em `terraform.tfvars`. A disponibilidade de versão depende da região, tenancy e serviço. Para um lab real de Deep Data Security, use uma versão compatível com Oracle AI Database 26ai.
## Banco Não É Acessível
Verifique:
- Cliente dentro da VCN ou conectado por VPN/FastConnect/bastion.
- NSG permitindo porta `1522`.
- Wallet e mTLS configurados.
- DNS do private endpoint resolvendo corretamente.
## Cenário SQL Falha
Verifique:
- Versão do banco compatível com Deep Data Security.
- Usuário executor com privilégio para criar schema, end users, data roles e data grants.
- Ordem dos scripts SQL.
- Se o cenário anterior foi resetado.
## Reset Não Remove Tudo
Execute o `sql/99_reset.sql` do cenário e valide manualmente objetos remanescentes. Em ambiente compartilhado, confirme antes de dropar schemas.

44
docs/validation.md Normal file
View File

@@ -0,0 +1,44 @@
# Validação
## Validação Local
Neste desktop, a execução direta de `.ps1` pode estar bloqueada por política do Windows. Use sempre:
```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\bootstrap.ps1
powershell -ExecutionPolicy Bypass -File .\scripts\validate-terraform.ps1
```
## Validação Terraform
O script executa:
```bash
terraform fmt -recursive -check
terraform init -backend=false
terraform validate
```
Depois de preencher `terraform.tfvars`, execute:
```bash
cd terraform/envs/demo
terraform init
terraform plan -out tfplan
terraform apply tfplan
```
## Validação Dos Cenários
Para cada cenário:
1. Execute `sql/99_reset.sql`.
2. Execute `00_schema.sql`, `01_seed_data.sql`, `02_identities.sql`, `03_data_grants.sql`.
3. Conecte como cada persona ou propague o contexto pela aplicação.
4. Execute `04_test_queries.sql`.
5. Compare com `evidence/expected-results.md`.
## Limites Da Validação Estática
`terraform validate` verifica sintaxe e schema do provider. Ele não garante disponibilidade regional de versão de banco, shape, quota, policies IAM ou limits de serviço. Esses pontos aparecem durante `terraform plan` e `terraform apply`.