Asegurar los servicios web públicos: ¿cuál es la mejor práctica? [cerrado]

Como dijo Tom Leek, la seguridad es un área ENORME. Cubre todo, desde secretos de seguridad, protocolos, activos, hasta privacidad, repudio, disponibilidad, recuperación de desastres, etc. Sé que comenzó la pregunta sobre los protocolos, estoy avanzando un poco más porque no sé si su percepción es que con solo agregar estos bastará para la seguridad, o si ya tiene todo lo demás asegurado y esta es la única área que queda.

Además, la seguridad está en toda la pila, en cualquier lugar, desde garantizar que no tenga errores de código (como los desbordamientos de búfer) hasta todos los parches de seguridad aplicados, hasta el diseño seguro general (cómo se autentican los usuarios, el control de acceso, etc.) ).

Tendrá que restringir específicamente lo que está tratando de asegurar, o si está buscando mejorar la seguridad en general, intente lo siguiente:

• Mire ISO 27034 y SDL de Microsoft , los cuales brindan una guía prescriptiva sobre cómo impulsar la seguridad en el proceso de desarrollo (Descargo de responsabilidad: trabajo para Microsoft y SDL es una de mis fuentes principales en el trabajo y en proyectos personales .)
• También puede consultar los libros de certificación, como los de CISSP o CCSK de Cloud Security Alliance, que se centrará más en varios principios de seguridad aplicables. Por supuesto, puede buscar más certificaciones y leer reseñas para elegir la mejor para su propósito.

Ambos de estos, esp. SDL de Microsoft (solo porque tengo un conocimiento íntimo de la misma) brindará una guía muy prescriptiva, y tiene enlaces a ella. He estudiado CISSP, pero eso es más de un nivel de Oficina de Seguridad Principal. Sin embargo, ambos son valiosos, pero si pudiera hacer solo uno, iría con SDL, o algún recurso que apunte a ISO 27034, o algo similar.

• Por último, no importa la cantidad de estas cosas que lea, tendrá que estar al tanto de los problemas de seguridad actuales y asegurarse de seguir aplicando correcciones. Por ejemplo, si tiene un sitio web, hay una gran cantidad de ataques en torno a XSS, XSRF, inyección SQL, bombas XML, etc. que deberá conocer y, dependiendo de las tecnologías que use, tendrá que asegurarse de que no estén expuestos. su servicio.
• Al igual que estos ataques, también deberá asegurarse de saber qué software externo está utilizando (incluido el sistema operativo) y cuáles son los problemas de seguridad más recientes y si ha aplicado todos los parches, etc. Esto significa apache , IIS, Linux, Windows, lo que sea. Por ejemplo, si usó OpenSSL (incluso si no lo sabía, pero su instalación, por ejemplo, lo tenía), sería mejor aplicar una solución para protegerse contra la vulnerabilidad de Heart Bleed.

En lo que respecta a los protocolos, por lo general, se trata de su diseño en torno a quién va a acceder, qué se está asegurando, etc., casi la mayoría de las preguntas que Tom Leek hizo. Entre algunos protocolos (como OAUTH y SAML), no es tanto que difieran en la seguridad (según sus necesidades), sino que diferentes partes son compatibles con diferentes partes con las que puede integrarse. Por ejemplo, la mayoría, si no todos, los IDP sociales (facebook, google, cuenta de Microsoft, linkedin, incluso stackexchange) son compatibles con OAUTH, y si los usara como su proveedor de identidad, se vería obligado a consumir OAUTH y token formatos soportados por cualquiera de estos.

Sin embargo, si estuviera actuando como su propio IDP, entonces tendría más opciones y consideraría si desea usar un directorio (especialmente si su organización ya tiene uno, como AD), o construir su propio . Un directorio normalmente proporcionará un conjunto de protocolos que admite para la autenticación. Si ya tiene un servicio de terceros que está utilizando su organización (por ejemplo, SAP, Salesforce, Office en línea), es posible que pueda usar la autenticación desde allí.

Espero que esto ayude.

Pedir la mejor práctica para garantizar algún servicio público, sin ningún otro detalle, es como preguntar cuál es el mejor automóvil. La única respuesta puede ser: depende. ¿Necesitas el coche para transportar maquinaria pesada? ¿Ir a trabajar de manera confiable incluso en una tormenta de nieve? ¿Deambular por las calles durante horas como parte de un grupo de vigilantes? ¿Para atraer a posibles parejas?

Ya que estamos hablando de generalidades, lo primero que hay que hacer es escribir el modelo de seguridad :

• ¿Qué activos intenta proteger?
• ¿Cuál es el alcance asumido del poder, la motivación y la paciencia de los atacantes?
• ¿Cuál es el valor de lo que proteges?

En particular, para un servicio público basado en la red, puede o no temer los siguientes casos (lista no exhaustiva):

• Un atacante envía una solicitud a su servicio sin estar autorizado para hacerlo.
• Un atacante espía los datos intercambiados entre su servicio y un usuario autorizado.
• Un atacante modifica una solicitud de un usuario autorizado a su servicio y / o modifica la respuesta.
• Un atacante se hace pasar por un clon falso de tu servicio y habla con tus usuarios sin que tu servicio se haya dado cuenta.
• Un atacante interrumpe tu servicio al sobrecargarlo.
• Un usuario autorizado espía a otros usuarios autorizados que acceden al servicio al mismo tiempo.
• Las autoridades legales le piden que proporcione la identidad del usuario que emitió una solicitud específica para su servicio, y está legalmente obligado a mantener dichos registros.
• Algunos eventos locales (inundación, incendio, ...) interrumpen su servicio y usted necesita activar un sitio secundario para mantener la disponibilidad.
• Los usuarios lo demandan por algunos supuestos marcos y debe tener una prueba, convincente para el juez, de que el usuario realmente le envió una solicitud específica que no pudo haber fabricado (un contexto bancario típico).
• Un atacante logró robar una parte de la base de datos de su servidor y la usa para hacerse pasar por usuarios.

Una variedad de herramientas será relevante, dependiendo de la situación. En la mayoría de los casos, el uso de SSL para su servicio será una buena idea (o, más bien, no usar SSL sería una idea espectacularmente mala). En muchos casos, necesitará algún tipo de autenticación de usuario.