Avec la requête ou le jeton approprié, un attaquant pourrait obtenir encore plus d’informations sur ces services et rechercher des vulnérabilités ou d’autres points d’entrée pour pénétrer dans les systèmes d’une organisation. Nous recommandons vivement aux entreprises d’utiliser actuellement OPA comme solution de politique en tant que code pour s’assurer qu’elles n’exposent pas involontairement leurs API et leurs politiques en ligne. Dans certains cas, les entreprises pourraient utiliser l’OPA sans s’en rendre compte ; Plusieurs fournisseurs de services gérés par Kubernetes s’appuient sur OPA pour l’application des politiques.
Gardez à l’esprit que nous n’avons interrogé le point de terminaison des politiques de liste de l’API REST que pour des raisons éthiques. Cependant, il existe de nombreux autres points de terminaison et méthodes disponibles qui non seulement répertorient les informations sensibles, mais permettent également à un attaquant de modifier ou même de supprimer des données et des objets d’un serveur OPA exposé. Certains d’entre eux sont :
|
Créer ou mettre à jour une politique |
PUT /v1/policies/ |
| Supprimer une politique | SUPPRIMER /v1/policies/ |
| Patcher un document (Data API) | PATCH /v1/data/{chemin :.+} |
| Supprimer un document (Data API) : | SUPPRIMER /v1/data/{chemin :.+} |
Tous ces éléments peuvent être trouvés dans la documentation de l’API REST OPA.
Protection des serveurs OPA
En premier lieu, les serveurs OPA ne doivent pas être exposés à Internet. Il est donc nécessaire de restreindre cet accès pour éviter que quiconque ne fouille dans vos configurations OPA via l’API REST. Le mode standard de déploiement d’OPA pour le cas d’utilisation d’autorisation consiste à exécuter OPA sur la même machine que l’application qui lui demande des décisions. De cette façon, les organisations n’auraient pas besoin d’exposer OPA à Internet ou au réseau interne, car la communication s’effectue via l’interface localhost. De plus, le déploiement d’OPA de cette manière signifie que les organisations n’auront généralement pas besoin d’activer l’authentification/autorisation pour l’API REST, car seul un processus s’exécutant sur la même machine serait en mesure d’interroger l’instance OPA. Pour ce faire, OPA peut être démarré avec “opa run –addr localhost:8181” pour qu’il se lie uniquement à l’interface localhost.
Deuxièmement, lors de l’utilisation d’un outil de stratégie en tant que code tel que OPA, il est important de protéger les stratégies dans un emplacement tel qu’un système de gestion de code source (SCM). Il est également essentiel de disposer de contrôles d’accès appropriés pour surveiller qui peut modifier quoi dans ces politiques via des fonctionnalités telles que la protection des succursales et le code des propriétaires. Grâce à la puissance du système SCM, les organisations peuvent créer un processus plus rationalisé d’examen et d’approbation de toute modification apportée à ces politiques, en s’assurant que tout ce qui se trouve dans le code source se reflète également dans les serveurs OPA de production.
TLS et HTTPS
Comme le montre la figure 4, la plupart de ces serveurs OPA exposés trouvés sur Shodan n’utilisaient aucun type de cryptage pour la communication, car cela n’est pas activé par défaut. Pour configurer TLS et HTTPS, les administrateurs système doivent créer un certificat et une clé privée, et fournir les indicateurs de ligne de commande suivants :
- Le chemin du certificat TLS: –tls-cert-file=
- Le chemin de la clé privée TLS : –tls-private-key-file=
Pour des informations à jour concernant ce processus, veuillez consulter la documentation OPA sur TLS et HTTPS.
Authentification et autorisation
Par défaut, les mécanismes d’authentification et d’autorisation OPA sont désactivés. Ceci est décrit dans la documentation officielle d’OPA, et il est essentiel que les administrateurs système et les ingénieurs DevOps activent ces mécanismes immédiatement après l’installation.
Les deux mécanismes peuvent être configurés via les indicateurs de ligne de commande suivants selon la documentation OPA :
- Authentification : –authentication=
.
Cela peut être des jetons au porteur (–authentification=jeton) ou des certificats TLS client (–authentification=tls). - Autorisation : –authorization=
.
Cela utilise les politiques Rego pour décider qui peut faire quoi dans OPA. Il peut être activé en réglant le –authorization=basic lors du démarrage d’OPA et fournissant une politique d’autorisation minimale.
Vous trouverez plus de détails sur ce processus dans la documentation officielle de l’OPA sur l’authentification et l’autorisation.
Recommandations de sécurité cloud
Kubernetes est l’une des plateformes les plus populaires parmi les développeurs, comme le prouve son taux d’adoption élevé qui ne montre aucun signe de ralentissement prochainement. Avec une base d’utilisateurs en constante expansion, les déploiements de Kubernetes doivent être protégés contre les menaces et les risques. Pour ce faire, les développeurs peuvent se tourner vers des outils de politique en tant que code, qui peuvent aider à mettre en œuvre des contrôles et à valider des procédures de manière automatisée.
En plus d’appliquer avec diligence certaines règles de gestion de base pour assurer la sécurité des clusters Kubernetes, les entreprises peuvent également bénéficier de solutions de sécurité spécifiques au cloud telles que Trend Micro™ Hybrid Cloud Security et Trend Micro Cloud One™.
Trend Micro aide les équipes DevOps à créer en toute sécurité, expédier rapidement et fonctionner n’importe où. La solution Trend Micro™ Hybrid Cloud Security fournit une sécurité puissante, rationalisée et automatisée au sein du pipeline DevOps de l’organisation et fournit plusieurs techniques de défense XGen™ pour protéger les charges de travail physiques, virtuelles et cloud contre les menaces. Il est alimenté par la plate-forme Cloud One™, qui offre aux organisations un aperçu unique de leurs environnements de cloud hybride et de la sécurité en temps réel via la sécurité du réseau, la sécurité de la charge de travail, la sécurité des conteneurs, la sécurité des applications, la sécurité du stockage des fichiers et Prestations de conformité.
Pour les organisations à la recherche d’une charge de travail d’exécution, d’une image de conteneur et d’une sécurité de stockage de fichiers et d’objets en tant que logiciel, Deep Security™ analyse les charges de travail et les images de conteneur à la recherche de logiciels malveillants et de vulnérabilités à tout intervalle du pipeline de développement pour prévenir les menaces avant qu’elles ne surviennent.
Trend Micro™ Cloud One™ est une plateforme de services de sécurité pour les créateurs de cloud. Il fournit une protection automatisée pour la migration vers le cloud, le développement d’applications cloud natives et l’excellence opérationnelle du cloud. Cela permet également d’identifier et de résoudre plus rapidement les problèmes de sécurité et d’améliorer les délais de livraison pour les équipes DevOps. Il comprend les éléments suivants :
.