Políticas IT NR
Reglas prácticas para features nuevas en Wealth Navigator y Wealth Mobile
Destinatarios: desarrollo, operaciones y soporte. Estas políticas se basan en la arquitectura real de Wealth Navigator (web/API FastAPI + React) y Wealth Mobile (Flutter iOS/Android). No sustituyen la documentación canónica de cada repo; la resumen para uso diario.
1. Alcance y principios
- Mínimo privilegio: cada feature hereda el modelo
recurso:accion:alcance(own→assigned→all). No ampliar alcance “por comodidad”. - Fail-closed en producción: 2FA obligatorio, CORS restringido, Integrity en Android, HTTPS fijo a
https://api.newroadai.comen builds prod de mobile. - Sin secretos en git ni en el cliente: keys, tokens de custodia, webhooks, Admin SDK Firebase y keystores viven en env/secrets del servidor o CI.
- IDs opacos: UUIDs públicos en contratos browser/mobile; nunca exponer PKs secuenciales ni inventar IDs en el cliente.
- Elevado riesgo por defecto: CRM, onboarding/NAF, documentos, banca, ETL, exports, retiros, recibos de referral y simulación de usuario requieren revisión explícita.
2. Autenticación, sesiones y MFA
Wealth Navigator (web)
- Login con OTP por email (challenge JWT → cookie HttpOnly
newroad_session). Google Sign-In solo acorta OTP para roles acotados (Investor, Advisor, Intern Advisor, Advisor Assistant, Referral). - Operaciones de control/admin/ETL deben respetar
mfa_verified. No debilitar 2FA ni usarDISABLE_2FA=truefuera de local. - Simulación de usuario (
user:simulate:all) es solo lectura (~30 min). No ampliar writes sin revisión de seguridad. - Basic Auth está rechazado a propósito: no reintroducirlo para “saltar” MFA.
Wealth Mobile
- Auth solo password contra
/api/v1/mobile/auth/*. Google Sign-In no existe en mobile. - La contraseña nunca se persiste. El JWT va en memoria; a Keystore/Keychain solo si el usuario activa biometría.
- Tras ~30s en background, forzar reingreso con remember-me. Pantallas de documentos deben reautenticar al entrar.
- Política de password nueva: mínimo 12 / máximo 128 (alineada al backend). Login legado puede aceptar ≥8 solo para contraseñas antiguas.
- Roles móviles efectivos:
InvestoryReferral. Usuario dual se resuelve como Referral. No mezclar shells de navegación.
3. Roles, permisos y alcance de datos
- Fuente de verdad de permisos: nomenclatura
recurso:accion:alcanceen Wealth Navigator. Frontend y backend deben coincidir; una ruta nueva sin permiso = bug. - Investor: solo
own(portfolios, cuentas, posiciones, transacciones). - Advisor / Intern / Assistant: datos de clientes
assigned, no firm-wide. - Operation / Backoffice / Control / Admin: privilegios altos (ETL, CRM write, roles). Cambios de rol o execute de ETL requieren control de cambios.
- En APIs: filtrar por alcance antes de resolver IDs. No autorizado o inexistente → mismo 404 (anti-enumeración / IDOR).
- El “blur” de privacidad en portfolios es UX para screen-share, no control de acceso.
4. PII, KYC, banca y datos financieros
- Tratar como confidencial: nombre, email, teléfono, dirección,
tax_id/DNI, cuentas bancarias/CCI, contratos NAF, documentos DNI/contratos, holdings, cashflows, comisiones y fees. - Documentos KYC/AML: cifrado AES-256-GCM en storage; usar servicios existentes, no inventar rutas de archivo en claro.
- Formularios públicos NAF: tokens con capability, rate-limit, sin KYC en contrato público. Compartir el link solo con el cliente destinatario y revocar al terminar.
- Soporte público: no pedir ni persistir contraseñas, OTP, tokens ni números de cuenta completos.
- Exports PDF/XLSX y factsheets compartidos: jobs con UUID del solicitante; tokens de share opacos y con vigencia.
- Mobile — retiros: monto, destino bancario, teléfono y comentarios son datos de ops/AML; no loguear el body.
- Mobile — referrals: PII del prospecto + DNI +
prospect_consent_confirmedobligatorio. Recibos PDF ≤10 MB con Integrity en Android. - Telemetría:
sendDefaultPii=false; no screenshots/replay en mobile; no loguear headers/bodies Dio; correlacionar conX-Request-ID.
5. Secretos, entornos y despliegue
- Producción: API
api.newroadai.com, frontwww/liberty. Staging aislado (DB/Redis). Previews de Pages no deben pegarse a la API de producción. - CORS prod solo orígenes allowlist (
www.newroadai.com,liberty.newroadai.com). Nunca localhost ni*.pages.devcontra prod. - No poner en
VITE_*ni dart-defines: URLs de Google Sheets/exec, webhooks Kapso, DB, Flex IBKR, service accounts, Admin Firebase. - Custodiar: IBKR Flex, AIS, Kapso/WhatsApp, Resend, Google OAuth/Calendar, Play Integrity, keystores Android, Firebase client configs.
- CI: gitleaks; no imprimir
.enven logs de deploy. Rotar ante cualquier exposición. - Mobile prod: origin API exacto HTTPS; cleartext bloqueado; channel
internalvsproduction; nunca shipPLAY_INTEGRITY_NEGATIVE_TESTfuera de QA interna.
6. Reglas específicas — Wealth Navigator
- Contratos nuevos preferir
/api/v2con UUIDs públicos; extender/api/v1solo si es inseparable. Compartir deps de auth/RBAC (deps.py), no bifurcar. - OpenAPI
/docsdeshabilitado en producción; no reactivarlo. - Webhooks Kapso: verificar HMAC del body; fallar cerrado sin secreto.
- Passwords temporales: solo generados en servidor; no devolver al SPA; no defaults tipo
password123. - Módulos de alto impacto (ETL, IB Gateway, Admin roles, CRM master, payments, market brief masivo): documentar en el mismo PR y seguir runbooks / module-impact-map.
- Audit logs: mutaciones y auth/admin/etl/mobile se persisten; no loguear secretos (usar redaction existente).
- Migraciones compatibles con blue/green; no romper lectura durante el deploy.
7. Reglas específicas — Wealth Mobile
- Stack: Flutter (no RN). Personas Investor vs Referral con routers separados.
- Operaciones sensibles deben decidir si requieren Play Integrity (login, reset password, create referral, receipts, documents, welcome PDFs). iOS App Attest aún puede estar en modo exempt: documentar el riesgo.
- Documentos: usar
EncryptedDocumentCache(AES-GCM, TTL plaintext ~10 min, wipe en resume/logout). No SharedPreferences para tokens. - No reintroducir permisos amplios de storage/media. Enlaces externos solo HTTPS (
parseHttpsUri). - Nora y copy de tiendas: no prometer asesoría/retornos. Legal vía disclosures existentes.
- Account deletion no es self-serve in-app: canal de soporte / proceso operativo NR.
- Reabrir Documents en Android investor requiere revalidar checklists Play (producto y seguridad) antes de promover.
- Evidence de release: sin tokens, Integrity payloads, FCM, device IDs ni pantallas con PII real.
- Certificate pinning no está implementado: no añadirlo sin plan de rotación/ops.
8. Checklist antes de abrir un PR / release
Permisos
¿Endpoint/ruta con RBAC y filtro own/assigned/all? ¿404 anti-IDOR?
Secretos
¿Nada sensible en Vite/dart-define/git? ¿Env documentado en ejemplo sin valores reales?
PII / logs
¿Sin bodies, OTPs, tax IDs, cuentas en logs/Sentry? ¿Consent en referrals?
Auth
¿MFA donde corresponde? ¿Mobile: Integrity / biometría / shells de rol intactos?
Entorno
¿CORS/API origin correctos? ¿Prod fail-closed? ¿Staging para previews?
Docs / ticket
¿Cambio de alto riesgo enlazado a Trello (implementación/petición) y docs del repo?
9. Soporte, tickets e incidentes
- En tickets (ver página Trello / Ticketing): incluir app, entorno, versión/release-channel,
X-Request-ID, rol afectado y pasos. Prohibido pegar passwords, OTP, JWT, dumps financieros o pantallas con PII de clientes reales. - Escalamiento de acceso/cuenta: flujos oficiales de reset móvil o soporte web; no editar DB “a mano” desde el repo mobile.
- Simulación de usuario solo para troubleshooting, con salida limpia de la sesión simulada.
- Ante exposición de secretos o posible IDOR: rotar credenciales, revisar audit/Sentry, y no cerrar hasta verificación.
- Contacto soporte producto (público): canales documentados en newroadai.com; el email operativo de desarrollo no sustituye el proceso de borrado/acceso legal.
Última actualización orientativa: agosto 2026. Ante conflicto, prevalecen AGENTS.md, docs de seguridad y matrices de permisos de cada repositorio NewRoad.