Initial Oracle Deep Data Security lab kit
This commit is contained in:
46
docs/architecture.md
Normal file
46
docs/architecture.md
Normal 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.
|
||||
|
||||
28
docs/demo-guide-executive.md
Normal file
28
docs/demo-guide-executive.md
Normal 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
23
docs/git-push.md
Normal 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
59
docs/lab-execution.md
Normal 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
26
docs/scenarios.md
Normal 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
29
docs/security-model.md
Normal 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
38
docs/troubleshooting.md
Normal 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
44
docs/validation.md
Normal 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`.
|
||||
|
||||
Reference in New Issue
Block a user