Nota
O acceso a esta páxina require autorización. Pode tentar iniciar sesión ou modificar os directorios.
O acceso a esta páxina require autorización. Pode tentar modificar os directorios.
Aplícase a esta recomendación da lista de verificación de seguridade ben arquitectada: Power Platform
| SE:09 | Establecer un réxime de probas completo que combine enfoques para previr problemas de seguridade, validar implementacións de prevención de ameazas e probar mecanismos de detección de ameazas. |
|---|
As probas rigorosas son a base dun bo deseño de seguridade. As probas son unha forma táctica de validación para garantir que os controis funcionan como se espera. As probas tamén son unha forma proactiva de detectar vulnerabilidades no sistema.
Establecer o rigor das probas mediante a cadencia e a verificación desde múltiples perspectivas. Deberías incluír puntos de vista de dentro para fóra que proben a plataforma e a infraestrutura e avaliacións de fóra para dentro que proben o sistema como un atacante externo.
Esta guía ofrece recomendacións para probar a postura de seguridade da túa carga de traballo. Implementa estes métodos de proba para mellorar a resistencia da túa carga de traballo aos ataques e manter a confidencialidade, a integridade e a dispoñibilidade dos recursos.
Definicións
| Termo | Definición |
|---|---|
| Probas de seguridade de aplicacións (AST) | Unha técnica do ciclo de vida do desenvolvemento de seguridade (SDL) de Microsoft que emprega metodoloxías de probas de caixa branca e caixa negra para comprobar se hai vulnerabilidades de seguridade no código. |
| Probas de caixa negra | Unha metodoloxía de probas que valida o comportamento da aplicación visible externamente sen coñecemento dos compoñentes internos do sistema. |
| Equipo azul | Un equipo que se defende dos ataques do equipo vermello nun exercicio de xogo de guerra. |
| Probas de penetración | Unha metodoloxía de probas que emprega técnicas de hacking ético para validar as defensas de seguridade dun sistema. |
| Equipo vermello | Un equipo que desempeña o papel dun adversario e intenta piratear o sistema nun exercicio de xogo de guerra. |
| Ciclo de vida do desenvolvemento de seguridade (SDL) | Un conxunto de prácticas proporcionadas por Microsoft que admiten os requisitos de garantía de seguridade e cumprimento. |
| Ciclo de vida do desenvolvemento de software (SDLC) | Un proceso sistemático e de varias etapas para o desenvolvemento de sistemas de software. |
| Probas de caixa branca | Unha metodoloxía de probas onde a estrutura do código é coñecida polo profesional. |
Estratexias clave de deseño
As probas son unha estratexia innegociable, especialmente para a seguridade. Permite descubrir e abordar problemas de seguridade de forma proactiva antes de que poidan ser explotados e verificar que os controis de seguridade que implementaches funcionan segundo o deseñado.
O alcance das probas debe incluír a aplicación, a infraestrutura e os procesos automatizados e humanos.
Nota
Esta guía fai unha distinción entre as probas e a resposta a incidentes. Aínda que as probas son un mecanismo de detección que idealmente arranxa problemas antes da produción, non se deben confundir coa corrección ou investigación que se realiza como parte da resposta a incidentes. O aspecto da recuperación tras incidentes de seguridade descríbese en *Recomendacións para a resposta a incidentes de seguridade*. ...
Participar na planificación das probas. Pode que o equipo de carga de traballo non deseñe os casos de proba. Esa tarefa adoita estar centralizada na empresa ou realizada por expertos en seguridade externos. O equipo de carga de traballo debería participar nese proceso de deseño para garantir que as garantías de seguridade se integren coa funcionalidade da aplicación.
Pensa coma un atacante. Deseña os teus casos de proba partindo da suposición de que o sistema foi atacado. Deste xeito, podes descubrir as posibles vulnerabilidades e priorizar as probas segundo corresponda.
Executar probas dun xeito estruturado e cun proceso repetible. Basea o teu rigor nas probas en torno á cadencia, os tipos de probas, os factores determinantes e os resultados desexados.
Usa a ferramenta axeitada para o traballo. Empregar ferramentas configuradas para traballar coa carga de traballo. Se non tes unha ferramenta, compra a ferramenta. Non o constrúas. As ferramentas de seguridade son moi especializadas e crear a túa propia ferramenta pode introducir riscos. Aproveita a experiencia e as ferramentas que ofrecen os equipos centrais de SecOps ou por medios externos se o equipo de carga de traballo non ten esa experiencia.
Configura entornos separados. As probas pódense clasificar como destrutivas ou non destrutivas. As probas non destrutivas non son invasivas. Indican que hai un problema, pero non alteran a funcionalidade para remedialo. As probas destrutivas son invasivas e poden danar a funcionalidade ao eliminar datos dunha base de datos.
As probas en contornas de produción ofrécenche a mellor información, pero son as que causan a maior interrupción. Tendes a facer só probas non destrutivas en entornos de produción. As probas en entornos non produtivos adoitan ser menos disruptivas, pero poden non representar con precisión a configuración do entorno de produción de xeitos importantes para a seguridade.
Podes crear un clon illado do teu ambiente de produción usando a función de copia de ambientes. Se tes configuradas canles de despregamento, tamén podes despregar as túas solucións nun ambiente de probas dedicado.
Avaliar sempre os resultados das probas. As probas son un esforzo en balde se os resultados non se empregan para priorizar accións e realizar melloras augas arriba. Documenta as directrices de seguridade, incluídas as mellores prácticas, que descubras. A documentación que recolle os resultados e os plans de corrección informa o equipo sobre as diversas formas en que os atacantes poden tentar violar a seguridade. Realizar formación regular en seguridade para desenvolvedores, administradores e probadores.
Ao deseñar os seus plans de probas, pense nas seguintes preguntas:
- Con que frecuencia esperas que se execute a proba e como afecta ao teu entorno?
- Cales son os diferentes tipos de probas que deberías executar?
Con que frecuencia esperas que se executen as probas?
Proba a carga de traballo regularmente para asegurarte de que os cambios non introduzan riscos de seguridade e de que non haxa regresións. O equipo tamén debe estar preparado para responder ás validacións de seguridade organizativas que se poidan realizar en calquera momento. Tamén hai probas que podes executar en resposta a un incidente de seguridade. As seguintes seccións ofrecen recomendacións sobre a frecuencia das probas.
Probas de rutina
As probas de rutina realízanse a unha cadencia regular, como parte dos seus procedementos operativos estándar e para cumprir os requisitos de conformidade. Poderíanse realizar varias probas a diferentes ritmos, pero a clave é que se realicen periodicamente e segundo un horario.
Deberías integrar estas probas no teu SDLC porque proporcionan unha defensa en profundidade en cada etapa. Diversificar o conxunto de probas para verificar as garantías de identidade, almacenamento e transmisión de datos e canles de comunicación. Realiza as mesmas probas en diferentes puntos do ciclo de vida para garantir que non haxa regresións. As probas rutineiras axudan a establecer un punto de referencia inicial. Non obstante, iso é só un punto de partida. A medida que descubres novos problemas nos mesmos puntos do ciclo de vida, engades novos casos de proba. As probas tamén melloran coa repetición.
En cada etapa, estas probas deberían validar o código que se engadiu ou eliminou ou os axustes de configuración que cambiaron para detectar o impacto deses cambios na seguridade. Deberías mellorar a eficacia das probas coa automatización, equilibrada con revisións por pares.
Considere executar probas de seguranza como parte dunha canle automatizada ou dunha execución de probas programada. Canto antes descubras problemas de seguridade, máis doado será atopar o código ou o cambio de configuración que os causa.
Non confíes só en probas automatizadas. Usa probas manuais para detectar vulnerabilidades que só a experiencia humana pode detectar. As probas manuais son boas para casos de uso exploratorios e para atopar riscos descoñecidos.
Probas improvisadas
As probas improvisadas proporcionan validación no tempo real das defensas de seguridade. As alertas de seguranza que poderían afectar á carga de traballo nese momento activan estas probas. Os mandatos organizativos poden requirir unha mentalidade de pausa e proba para verificar a eficacia das estratexias de defensa se a alerta se converte nunha emerxencia.
A vantaxe das probas improvisadas é a preparación para un incidente real. Estas probas poden ser unha función de forzamento para facer probas de aceptación do usuario (UAT).
O equipo de seguridade pode auditar todas as cargas de traballo e executar estas probas segundo sexa necesario. Como propietario da carga de traballo, debes facilitar e colaborar cos equipos de seguridade. Negocia un prazo suficiente cos equipos de seguridade para que poidas prepararte. Recoñece e comunica ao teu equipo e ás partes interesadas que estas interrupcións son necesarias.
Noutros casos, pode que teñas que executar probas e informar do estado de seguranza do sistema fronte á posible ameaza.
Compromiso Dado que as probas improvisadas son eventos disruptivos, prepárate para repriorizar as tarefas, o que pode atrasar outros traballos planificados.
Risco: Existe o risco do descoñecido. As probas improvisadas poden ser esforzos puntuais sen procesos ou ferramentas establecidos. Pero o risco predominante é a posible interrupción do ritmo dos negocios. Debes avaliar eses riscos en relación cos beneficios.
Probas de incidentes de seguridade
Hai probas que detectan a causa dun incidente de seguridade na súa orixe. Estas lagoas de seguridade deben resolverse para garantir que o incidente non se repita.
Os incidentes tamén melloran os casos de proba co paso do tempo ao descubrir lagoas existentes. O equipo debería aplicar as leccións aprendidas do incidente e incorporar melloras de forma rutineira.
Cales son os diferentes tipos de probas?
As probas pódense clasificar por tecnoloxía e por metodoloxías de proba. Combina esas categorías e enfoques dentro desas categorías para obter unha cobertura completa.
Ao engadir varias probas e tipos de probas, podes descubrir:
- Lagoas nos controis de seguridade ou nos controis compensatorios.
- Configuracións incorrectas.
- Lagoas nos métodos de observabilidade e detección.
Un bo exercicio de modelado de ameazas pode sinalar áreas clave para garantir a cobertura e a frecuencia das probas. Para obter recomendacións sobre a modelización de ameazas, consulte *Recomendacións para protexer un ciclo de vida de desenvolvemento* .
A maioría das probas descritas nestas seccións pódense executar como probas de rutina. Non obstante, a repetibilidade pode supoñer custos nalgúns casos e causar interrupcións. Considera esas compensacións coidadosamente.
Probas que validan a pila tecnolóxica
Aquí tes algúns exemplos de tipos de probas e as súas áreas de enfoque. Esta lista non é exhaustiva. Proba toda a pila, incluíndo a pila de aplicacións, o front-end, o back-end, as API, as bases de datos e calquera integración externa.
- Seguridade dos datos: Proba a eficacia do cifrado de datos e dos controis de acceso para garantir que os datos estean debidamente protexidos contra o acceso non autorizado e a manipulación.
- Rede e conectividade: Proba os teus cortafuegos para asegurarte de que só permiten o tráfico esperado, permitido e seguro para a carga de traballo.
- Aplicación: Proba o código fonte mediante técnicas de probas de seguranza de aplicacións (AST) para asegurarte de que segues prácticas de codificación seguras e para detectar erros de tempo de execución como corrupción de memoria e problemas de privilexios.
- Identidade: Avaliar se as asignacións de roles e as comprobacións condicionais funcionan segundo o previsto.
Metodoloxía de probas
Hai moitas perspectivas sobre as metodoloxías de proba. Recomendamos probas que permitan a caza de ameazas simulando ataques do mundo real. Poden identificar potenciais actores de ameazas, as súas técnicas e as súas vulnerabilidades que supoñen unha ameaza para a carga de traballo. Fai que os ataques sexan o máis realistas posible. Emprega todos os vectores de ameaza potenciais que identifiques durante a modelización de ameazas.
Aquí tes algunhas vantaxes de realizar probas mediante ataques no mundo real:
- Cando fas que estes ataques formen parte das probas rutineiras, empregas unha perspectiva de fóra cara a dentro para comprobar a carga de traballo e asegurarte de que a defensa pode soportar un ataque.
- En función das leccións aprendidas, o equipo mellora os seus coñecementos e habilidades. O equipo mellora a conciencia situacional e pode autoavaliar a súa preparación para responder a incidentes.
Algúns exemplos de probas simuladas inclúen probas de caixa negra e caixa branca, probas de penetración e exercicios de xogos de guerra.
Probas de caixa negra e caixa branca
Estes tipos de probas ofrecen dúas perspectivas diferentes. Nas probas de caixa negra, os compoñentes internos do sistema non son visibles. Nas probas de caixa branca, o tester ten un bo coñecemento da aplicación e mesmo ten acceso ao código, rexistros, topoloxía de recursos e configuracións para realizar o experimento.
Probas que simulan ataques mediante probas de penetración
Os expertos en seguridade que non forman parte dos equipos de TI ou de aplicacións da organización realizan probas de penetración ou *pentesting*. Observan o sistema do mesmo xeito que os actores maliciosos exploran unha superficie de ataque. O seu obxectivo é atopar lagoas de seguridade recompilando información, analizando vulnerabilidades e comunicando os resultados.
Os profesionais poderían precisar acceder a datos confidenciais de toda a organización. Siga as normas de participación para garantir que o acceso non se faga de forma indebida. Consulta os recursos listados en Información relacionada.
Probas que simulan ataques mediante exercicios de xogos de guerra
Nesta metodoloxía de ataques simulados, hai dous equipos:
- O/A vermello O equipo é o adversario que intenta modelar ataques do mundo real. Se teñen éxito, atopas lagoas no teu deseño de seguridade e avalías o radio de contención das súas brechas.
- O/A azul O equipo é o equipo de carga de traballo que se defende contra os ataques. Ponen a proba a súa capacidade para detectar, responder e remediar os ataques. Validan as defensas que se implementaron para protexer os recursos da carga de traballo.
Se se realizan como probas rutineiras, os exercicios de xogos de guerra poden proporcionar visibilidade continua e a garantía de que as túas defensas funcionan segundo o deseñado. Os exercicios de xogos de guerra poden potencialmente probar diferentes niveis dentro das túas cargas de traballo.
Unha opción popular para simular escenarios de ataque realistas é Microsoft Defender para Office 365 Adestramento en simulación de ataque.
Para obter máis información, consulte *Informes e información sobre o adestramento en simulación de ataques* .
Para obter información sobre a configuración dos equipos vermellos e azuis, consulte Microsoft Cloud Red Teaming.
Power Platform facilitación
A solución Microsoft Sentinel para Microsoft Power Platform permite aos clientes detectar diversas actividades sospeitosas, como:
- Power Apps execución desde zonas xeográficas non autorizadas
- Destrución de datos sospeitosa por Power Apps
- Eliminación masiva de Power Apps
- Ataques de phishing realizados a través de Power Apps
- Power Automate actividade dos fluxos dos empregados que marchan
- Microsoft Power Platform conectores engadidos a un ambiente
- Actualización ou eliminación de políticas de datos Microsoft Power Platform
Para obter máis información, consulte a solución de Microsoft Sentinel para obter Microsoft Power Platform información xeral.
Para obter a documentación do produto, consulte Capacidades de busca en Microsoft Sentinel.
Microsoft Defender para a nube ofrece análise de vulnerabilidades para varias áreas tecnolóxicas. Para obter máis información, consulte Activar a análise de vulnerabilidades con Microsoft Defender Vulnerability Management.
A práctica de DevSecOps integra as probas de seguridade como parte dunha mentalidade de mellora continua. Os exercicios de xogos de guerra son unha práctica común que está integrada no ritmo de negocios de Microsoft. Para obter máis información, consulte Seguridade en DevOps (DevSecOps).
Azure DevOps admite ferramentas de terceiros que se poden automatizar como parte das canles de integración continua/implementación continua (CI/CD). Para obter máis información, consulte Activar DevSecOps con Azure e GitHub.
Información relacionada
As últimas probas de penetración e avaliacións da seguranza pódense atopar no Portal de confianza do servizo de Microsoft.
Microsoft realiza probas exhaustivas dos servizos de Microsoft Cloud. Estas probas inclúen probas de penetración, cuxos resultados se publican no portal de confianza de servizos da súa organización. A súa organización pode realizar a súa propia proba de penetración en servizos Microsoft Power Platform e Microsoft Dynamics 365. Todas as probas de penetración deben seguir as Regras de participación das probas de penetración na nube de Microsoft. É importante lembrar que, en moitos casos, Microsoft Cloud usa infraestrutura compartida para aloxar os teus activos e os activos que pertencen a outros clientes. Debes limitar todas as probas de penetración aos teus activos e evitar consecuencias non desexadas para outros clientes que te rodean.
Siga as regras de participación para asegurarse de que o acceso non se faga de forma indebida. Máis información sobre a planificación e execución de ataques simulados:
Podes simular ataques de denegación de servizo (DoS) en Azure. Asegúrate de seguir as políticas establecidas nas probas de simulación de Azure DDoS Protection.
Lista de verificación de seguridade
Consulta o conxunto completo de recomendacións.