Guardamos tu clave SOL—
y acá te contamos exactamente cómo.

La verdad sobre tu clave SOL

Para sincronizar el buzón, el SIRE, el 621 y la emisión de cada empresa, acc7 usa las credenciales SOL que registras. Preferimos explicarte cómo las protegemos antes de que tengas que preguntarlo.

Por qué te la pedimos

Las credenciales SOL son la llave de cada empresa ante SUNAT. Para emitir comprobantes SUNAT ni siquiera acepta el usuario principal del RUC: acc7 crea un usuario secundario con los permisos justos, y ese sí lo desactivas desde tu propio SOL sin tocar tu clave maestra. Es lo más parecido a un token revocable que SUNAT permite hoy (acá está el detalle).

Cómo se guardan

La clave SOL, el certificado digital (.p12) con su contraseña y la clave de AFPNet se guardan separadas por empresa y sólo se usan para sincronizar con SUNAT; entre tu equipo y acc7, y entre acc7 y SUNAT, todo viaja cifrado por TLS. Para emitir se usa un usuario secundario y no tu usuario principal, y lo puedes revocar desde tu propio SOL sin cambiar la clave del titular. Nada irreversible —presentar, dar de baja, tramitar un certificado— ocurre sin que un humano lo confirme, y cada acción queda en un log de auditoría que la aplicación sólo sabe escribir: no hay forma de editarlo ni de borrarlo desde el producto. Los XML, los CDR y los PDF del buzón no viven en la base de datos: van a un almacén de objetos aparte. Y nadie de tu estudio ve más de lo que le toca: el rol define qué módulos abre, qué empresas alcanza y si escribe o solo mira. Tu cliente, con su propio acceso, ve su RUC y ninguno de los demás.

Qué nunca sale de acc7

Hay datos que entran y no vuelven a salir, ni siquiera para ti. La clave de AFPNet es de solo escritura: la API la recibe y jamás la devuelve. El enlace con el que RENIEC entrega tu certificado es una URL-capacidad —quien la tenga le pone la contraseña y se lleva el certificado—, así que se guarda para poder reintentar el trámite y nunca viaja por la API: hacia afuera sale un sí o un no de si el enlace sigue vivo, nada más. Y ninguna consulta, export ni respuesta de la API devuelve la contraseña de tu .p12.

Debajo del capó

  • Un registro que nadie edita

    Cada acción que acc7 ejecuta —presentar, emitir, aceptar una propuesta del SIRE, tocar una credencial— escribe su fila en el log de Auditoría: quién, sobre qué empresa, qué cambió y cuándo. Ese log no se edita ni se borra, tampoco desde adentro, y lo lees tú mismo cuando quieras: es tu prueba, no nuestra palabra. SOC 2 e ISO 27001 están en el roadmap; mientras no las tengamos no vamos a pintar un sello. Un log que puedes auditar hoy vale más que un logo que nadie audita.

  • El stack se vigila cada 30 segundos

    Un vigía recorre cada servicio del sistema cada 30 segundos y lo deja en ACTIVO, DEGRADADO o CAÍDO, con su historial de latencia y el incidente abierto en el minuto exacto en que algo dejó de responder. No es una promesa de disponibilidad: es la misma pantalla que miramos nosotros. Y cuando un proceso se reintenta —porque SUNAT se cayó a mitad, porque la conexión se cortó— no duplica nada: todo entra por su clave natural, un comprobante por su CAR, un trabajador por empresa y DNI, y volver a correrlo deja el mismo resultado.

  • Lo irreversible se confirma a mano

    Presentar una declaración, dar de baja un comprobante o tramitar un certificado ante SUNAT nunca ocurre solo: va detrás de un modal donde alguien confirma, y los trámites desatendidos exigen que enciendas la autorización empresa por empresa. Al agente le pusimos un veto extra: por voz no se emite. Emitir un comprobante o apagar la vista previa están prohibidos en un turno hablado, porque una palabra mal transcrita no puede costar un comprobante ante SUNAT. Y el audio se transcribe en un servidor propio, no en el de un tercero, porque lleva tu RUC y tus montos.

Programa de seguridad

El OWASP Top 10, punto por punto

El Top 10 de OWASP es la lista estándar de los diez riesgos que hunden aplicaciones web, y es contra la que se revisa nuestro código. Acá está entera, con el estado real de cada punto: 7 cubiertos y 3 en curso, y en los tres que faltan decimos qué falta. La revisamos en cada edición del listado y cada vez que tocamos el modelo de accesos.

  • A01

    Pérdida de control de acceso

    Cubierto

    Cada campo de la API se autoriza antes de ejecutarse, contra una tabla explícita de campo · módulo · nivel · escritura. Un campo nuevo sin su fila no queda abierto: se rechaza. Tu cliente sólo alcanza su propia empresa, y un asistente con cartera asignada sólo las suyas.

  • A02

    Fallas criptográficas

    En curso

    Las contraseñas de acceso se guardan con Argon2 y no se pueden leer de vuelta; todo el tráfico va por TLS. Lo que falta lo decimos igual: la clave SOL y la contraseña de tu certificado todavía se guardan sin cifrar en la base, porque la sincronización con SUNAT necesita el valor original. Cifrarlas con una llave que viva fuera de la base es el trabajo en curso.

  • A03

    Inyección

    Cubierto

    Ninguna consulta se arma pegando texto: van parametrizadas y verificadas contra el esquema real en tiempo de compilación — unas 350 sólo en el backend. Un RUC con comillas es un RUC inválido, nunca un comando.

  • A04

    Diseño inseguro

    Cubierto

    Los permisos no viven en el botón. El gate que decide si una empresa puede emitir se aplica en el servidor, porque la API es alcanzable sin pasar por la pantalla. Lo irreversible se confirma a mano, lo desatendido se enciende empresa por empresa, y por voz no se emite.

  • A05

    Configuración defectuosa

    Cubierto

    En producción el explorador de la API queda apagado y el CORS se limita a los dominios declarados. Las herramientas internas de diagnóstico sólo escuchan en la máquina local, o exigen un token aparte.

  • A06

    Componentes vulnerables o desactualizados

    En curso

    Las dependencias están fijadas a versión exacta, para que nada cambie por sorpresa. Falta lo automático: el escaneo de vulnerabilidades conocidas en cada cambio, y la política escrita de en cuánto tiempo se parcha cada severidad.

  • A07

    Fallas de identificación y autenticación

    En curso

    Las sesiones caducan, las descargas sensibles usan un permiso de un solo uso que vive 5 minutos, cada agente instalado tiene su credencial hasheada, y para SUNAT puedes registrar un usuario secundario que se revoca sin tocar la clave del titular. En curso: límite de intentos contra fuerza bruta y segundo factor para el estudio.

  • A08

    Integridad del software y de los datos

    Cubierto

    Los cambios de base de datos van versionados y con verificación de integridad. Todo lo que se reintenta entra por su clave natural —un comprobante por su CAR, un trabajador por empresa y DNI—, así que reprocesar un lote no duplica ni pisa nada.

  • A09

    Registro y monitoreo

    Cubierto

    El log de Auditoría sólo sabe crecer: la aplicación no tiene manera de editarlo ni de borrarlo, y lo lees tú. Los servicios reportan por un estándar abierto, y un vigía los recorre cada 30 segundos y abre el incidente en el minuto exacto en que algo dejó de responder.

  • A10

    Falsificación de peticiones del lado del servidor (SSRF)

    Cubierto

    acc7 habla con una lista corta y fija de destinos: SUNAT, tu OSE, AFPNet y el padrón. No hay ningún punto de entrada donde alguien pueda darnos una dirección para que la vayamos a visitar.

Certificaciones: dónde estamos, de verdad

Hoy no tenemos ninguno de estos sellos, y no vamos a pintar uno. Están en preparación y, cuando existan, acá va cada uno con su fecha, su alcance y quién lo emitió. Mientras tanto lo que te ofrecemos es esto: el detalle de arriba, y un log de Auditoría que compruebas tú mismo sin pedirnos permiso.

  • En preparación

    SOC 2 Tipo II

    El informe que audita cómo operamos durante meses, no cómo estamos un día. Es el que suele pedir un estudio grande antes de mover su cartera. Primero cerramos el cifrado en reposo: certificar alrededor de una deuda conocida no sirve de nada.

  • En preparación

    ISO/IEC 27001

    La norma internacional del sistema de gestión de seguridad: políticas, responsables, gestión de incidentes y revisión periódica, escritos y auditados por un tercero.

  • Trabajo en curso

    Ley 29733 · Protección de Datos Personales

    La obligación peruana, y la que aplica primero: bancos de datos declarados ante la Autoridad Nacional, encargados de tratamiento identificados y un procedimiento real para ejercer tus derechos sobre lo que guardamos de ti y de tus clientes.

¿Encontraste un problema de seguridad en acc7? Escríbenos a seguridad@acc7.pe antes de publicarlo: respondemos, lo arreglamos y te decimos cuándo quedó cerrado.

Pregúntanos lo que falte

Si algo de esta página no te cierra, escríbenos antes de confiarnos una clave.