> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-es/kilo-center/kilo-mioty-service-center/security/security-basics.md).

# Conceptos básicos de seguridad

Conceptos básicos de seguridad de KiloCenter — credenciales predeterminadas que deben cambiarse, rutas de certificados TLS y endurecimiento mínimo para despliegues compartidos.

### Objetivo

Establezca una línea base segura para las implementaciones de KiloCenter.

### Credenciales predeterminadas

El desarrollo local incluye credenciales de conveniencia que deben cambiarse para cualquier entorno compartido o de producción:

| Servicio    | Predeterminado                              | Notas                                                    |
| ----------- | ------------------------------------------- | -------------------------------------------------------- |
| PostgreSQL  | usuario `kilocenter`, contraseña `changeme` | Cambiar en `config.yaml` y Docker Compose                |
| broker MQTT | usuario `admin`, contraseña `KiloCenter`    | Cambiar en la configuración de Mosquitto y `config.yaml` |

### TLS para la comunicación entre la estación base y el centro de aplicaciones

BSSCI requiere TLS 1.2 o superior. SCACI requiere TLS 1.3 o superior. Cada conexión a KC-Core usa cifrado TLS.

#### Modelo de confianza de CA

KiloCenter utiliza una Autoridad de Certificación (CA) autofirmada para emitir todos los certificados:

| Certificado                | Propósito                                            | Validez predeterminada | Ubicación                 |
| -------------------------- | ---------------------------------------------------- | ---------------------- | ------------------------- |
| Certificado de CA          | Raíz de confianza; distribuido a las estaciones base | 20 años                | `certificates/ca.crt`     |
| Clave privada de CA        | Firma certificados de servidor y cliente             | --                     | `certificates/ca.key`     |
| Certificado de servidor    | Listeners TLS de KC-Core BSSCI/SCACI                 | 1 año                  | `certificates/server.crt` |
| Clave privada del servidor | Negociación TLS                                      | --                     | `certificates/server.key` |
| Certificado de cliente     | TLS mutuo por estación base (opcional)               | 1 año                  | Generado bajo demanda     |

Las estaciones base confían en la **Certificado de CA**, no en certificados de servidor individuales. Esto significa que los certificados del servidor se pueden renovar sin tocar las estaciones base, siempre que la misma CA los firme.

Si vuelve a generar la CA, todos los certificados existentes de servidor y cliente dejarán de ser válidos y deberán volver a emitirse. Haga una copia de seguridad de `ca.key` de forma segura.

#### Generación de certificados

**Generar certificados de CA + servidor (configuración inicial)**

No se requiere la toolchain de Go del host — use el `certgen` servicio compose:

```bash
docker compose run --rm certgen
```

> **Propiedad de los archivos (Linux):** Si los archivos generados pertenecen a root, vuelve a ejecutarlo con `UID=$(id -u) GID=$(id -g)` antepuesto.

Para un FQDN de producción:

```bash
docker compose run --rm certgen -dir /app/certificates -days 365 -server bssci.example.com
```

Esto crea cuatro archivos en `KC-Core/certificates/`:

* `ca.crt` y `ca.key` -- certificado de CA y clave privada
* `server.crt` y `server.key` -- certificado del servidor y clave privada

El certificado del servidor incluye automáticamente `localhost`, `127.0.0.1`, `0.0.0.0`y todas las IPs de la red local como Nombres Alternativos del Sujeto (SAN).

**Generar un certificado de cliente**

```bash
docker compose run --rm certgen \
    -dir /app/certificates -client-only -client 70-B3-D5-9C-D0-00-09-E6
```

**Referencia de certgen**

| Opción         | Predeterminado | Descripción                                                                         |
| -------------- | -------------- | ----------------------------------------------------------------------------------- |
| `-dir`         | `certs`        | Directorio de salida para los archivos de certificado                               |
| `-server`      | `localhost`    | Nombre del host del servidor (usado como CN y SAN)                                  |
| `-days`        | `365`          | Validez del certificado de servidor/cliente en días                                 |
| `-ca-years`    | `20`           | Validez del certificado de CA en años                                               |
| `-ca-only`     | `falso`        | Generar solo el certificado de CA                                                   |
| `-server-only` | `falso`        | Generar solo el certificado del servidor (la CA ya debe existir)                    |
| `-client-only` | `falso`        | Generar solo un certificado de cliente (la CA ya debe existir)                      |
| `-client`      | (vacío)        | Nombre del cliente para el certificado de cliente (p. ej., EUI de la estación base) |

**Escenarios comunes**

**Renovar solo el certificado del servidor (la CA ya existe):**

```bash
docker compose run --rm certgen \
    -dir /app/certificates -server bssci.example.com -server-only
```

#### Rotación de certificados

**Mediante compose** (recomendado para automatización):

```bash
docker compose run --rm certgen \
    -dir /app/certificates -server bssci.example.com -server-only
docker compose restart kilocenter
```

**Mediante la interfaz gráfica** (renovación posterior a la instalación):

1. Abra KC-Web y vaya a **Certificados**.
2. Haz clic en **Renovar certificados del servidor** y confirme.
3. Reinicie KC-Core para cargar los nuevos certificados.

**Después de la rotación:**

1. Reinicie KC-Core para cargar los nuevos certificados.
2. Verifique que las reconexiones de las estaciones base se realicen correctamente.
3. Si se cambió la CA, redistribuya `ca.crt` a todas las estaciones base.

#### Configuración de certificados

KC-Core carga los certificados desde las rutas configuradas en `config.yaml` (desarrollo local) o `config/config.docker.yaml` (contenedor):

```yaml
protocol:
  bsci_tls:
    enabled: true
    cert_file: "certificates/server.crt"
    key_file: "certificates/server.key"
    ca_file: "certificates/ca.crt"
    min_version: "1.2"
  scaci_tls:
    enabled: true
    cert_file: "certificates/server.crt"
    key_file: "certificates/server.key"
    ca_file: "certificates/ca.crt"
    min_version: "1.3"
```

Las rutas en el modo de desarrollo local son relativas al directorio de trabajo de KC-Core. KC-Core no podrá iniciarse si faltan estos archivos.

### Exposición de red

Limite qué puertos son accesibles desde fuera de su red local:

| Puerto | Servicio                | Recomendación de exposición               |
| ------ | ----------------------- | ----------------------------------------- |
| 5000   | BSSCI                   | Solo redes de estaciones base             |
| 5001   | SCACI                   | Solo hosts del centro de aplicaciones     |
| 9090   | KC-Gateway (gRPC-web)   | Redes de operadores y consumidores de API |
| 80     | KC-Web (contenedor)     | Solo redes de operadores                  |
| 50051  | gRPC interno de KC-Core | Solo loopback, nunca exponer externamente |
| 5433   | PostgreSQL              | Solo loopback                             |
| 6379   | Redis                   | Solo loopback                             |
| 1883   | MQTT                    | Solo redes consumidoras de MQTT           |

### Lista de verificación de endurecimiento

* [ ] Rote todas las credenciales predeterminadas enumeradas arriba
* [ ] Restrinja el acceso de red a los puertos de administración (50051, 5433, 6379)
* [ ] Almacene las claves privadas de los certificados con permisos de archivo restringidos
* [ ] Habilite el registro a nivel de auditoría en entornos de producción
* [ ] Revise `config.yaml` cualquier valor predeterminado de desarrollo restante

### Edición Enterprise

La Edición Enterprise añade funciones de seguridad multicliente:

* Autenticación de usuarios con validación JWT
* Aislamiento de datos por organización
* Control de acceso basado en roles

Estas funciones no están disponibles en la Edición Community.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kiloiot.io/kilo-docs-es/kilo-center/kilo-mioty-service-center/security/security-basics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.