Esto se puede estimar, utilizando los Rainbow Books que definen la seguridad de la información.
El enfoque descrito establece que todo (incluidos los paquetes de red) debe tener controles de acceso obligatorios. Por lo tanto, no puede conectar un cliente a un servidor a menos que haya controles de acceso obligatorios en ambos y uno pueda conectarse al otro y la red intermedia esté autorizada para transportar esos paquetes. No hay ningún requisito para el cifrado, etc., en este punto, solo un requisito de que todo tiene autoridad limitada y todo estipula qué autoridad se requiere. La forma en que implemente eso depende de usted.
Sin embargo, muchas capas profundas que desee modelar son irrelevantes. Ya sea que esté utilizando CORBA 3 a través de un overnet a través de una red física o algún ingenioso esquema de clasificación de paquetes que simule todo eso mediante la asignación de una clasificación adecuada, se trata prácticamente del mismo proceso.
- ¿Con qué frecuencia se viola la garantía de pedido de TCP en la práctica para implementaciones comunes de TCP?
- ¿Por qué no se utiliza TCP en IoT?
- Cómo encontrar mi teléfono con mi dirección IP
- ¿Puede IPv6 reemplazar completamente a Ethernet (e incluso algunas partes de TCP)?
- ¿Puedo acceder a una PC solo desde una dirección IP?
Si tiene un servidor de permisos, similar a Kerberos pero de múltiples capas, entonces los cálculos ya están hechos. Solicita un boleto para un objetivo dado y si le dan uno, entonces el objetivo está bien. Todas las capas solo validan el ticket. Así que son operaciones de ticket 2n-1 para descender y ascender una pila de n capas, incluido el software que obtiene el ticket, con solo una pieza central, no dos.
Si solicita permisos directamente de una capa, autentica el par ordenado de (solicitante, recurso) de un validador MAC como parte de un protocolo de enlace, donde hay protocolos de enlace 4n-1 (aplicación de usuario + usuario, multiplicado por arriba y abajo de la tubería, menos el hecho de que el medio se hace una vez).
Usaría un esquema de overnet, como X-bone o MPLS, para manejar el aislamiento del tráfico y usar IPSec de host a host (que puede ser sobre la marcha o usar un servidor de claves) para todo el tráfico.
¿Almacenamiento?
Bueno, las entradas serían insignificantes. Creo que 512 bits serían suficientes para proporcionar tokens seguros, donde solo necesita un ticket para cada conexión de extremo a extremo. Un servidor que trabaje con 2048 conexiones simultáneas necesitaría 1k bytes de búfer para contener una matriz de tokens.
El servidor de tickets necesitaría datos similares a los almacenados para SELinux: un objeto hereda los permisos de un conjunto de objetos y filtra los permisos de un conjunto de otros objetos. Esto solo debe hacerse una vez en una LAN y no incluiría nada que no sea aplicable. En escenarios típicos (la persona X no puede jugar juegos después de acostarse, la persona Y solo puede usar WAN corporativa para aplicaciones de trabajo y acceso a correo electrónico IMAP4, web y túnel solo en la conexión regular), estás hablando quizás ocho 512 bits ID (4k de datos) para proporcionar la información MAC.
Luego debe almacenar los tokens válidos, a quién pertenecen y el momento de caducidad. 512 + 512 + 64 = 1088 bits para una entrada de permiso mínima. En el caso del servidor, dado que necesita conservar información sobre los permisos en cada sentido, tiene poco más de 4 megabytes para autenticar todo lo necesario.
Mi primera computadora con Linux fue una Viglen 386SX con cinco megabytes de RAM (la memoria extendida no estaba equilibrada con la memoria principal). Podría haber ejecutado el sistema de autenticación para dicho servidor, simplemente, ya que el núcleo no necesitaba un megabyte y la aplicación podría ser increíblemente pequeña.
Recursos informáticos? El host obtiene el uuid para el usuario y el proceso (esencialmente gratis), lo envía al servidor que realiza la sustracción establecida para ver si la combinación es válida, con un token de 512 bits devuelto. Esta es la parte lenta, pero se realiza una vez cuando se realiza la conexión. Después de eso, solo necesita ver si el token es válido. Si es válido, la autoridad que otorga es válida.
Un Arduino o Raspberry Pi con ocho megas de RAM admitiría un segmento LAN correctamente subdividido en una corporación, aunque podría ser un poco lento. Este es casi el nivel de llavero. Si las conexiones son sostenidas en lugar de esporádicas, podría construir un servidor de autenticación en un llavero.
Si desea un poco más de empuje, empújelo junto con un sistema de detección de intrusiones de red activa en una PC sin disco. Tenga el sistema operativo, el disco raíz, la aplicación y la base de datos central en un disco RAM flash. Si puede encontrar algo tan pequeño como una memoria RAM de gigabyte, cargue las imágenes en la RAM dinámica y ejecute la lógica establecida más el caché de token allí. El NIDS activo bloquea el cortafuegos contra intrusos, por lo tanto, tenga un conjunto de reglas que si una conexión carece de un token válido, la conexión se suprime temporalmente.
Este sistema se encargará de OSI, las capas TCP / IP, capas en capas y absolutamente cualquier otra cosa que desee con casi ningún gasto adicional. Debe agregar muy poco para crear una enorme cantidad de combinaciones válidas adicionales de permisos y no debe haber redundancia en ningún lado.
Existen fallas en este diseño, pero no las que aumentan sustancialmente los requisitos de almacenamiento o CPU, por lo que podemos usar esto como una guía, incluso si nunca escribiría el sistema de esta manera precisa.
