Dans « Comment SQL peut unifier l’accès aux API », j’ai présenté SQL comme un environnement commun dans lequel raisonner sur les données provenant de nombreuses API différentes. Le catalyseur clé de ce scénario est Steampipe, un outil basé sur Postgres avec une suite croissante de plugins d’API qui mappent les API à des tables étrangères dans Postgres.
Ces API étaient initialement celles fournies par AWS, Azure et GCP. Ces API sont généralement rendues plus accessibles aux développeurs grâce à des wrappers comme boto3< /a>. Une interface SQL commune est sans doute un meilleur unificateur des écosystèmes d’API tentaculaires au sein de ces nuages, et c’est incontestablement vrai dans les scénarios multicloud. Avec Postgres sous le capot, au fait, vous n’êtes pas limité à SQL : vous pouvez raccorder Python ou JavaScript ou un autre langage à Postgres et tirer parti de l’interface SQL commune de ces langages également.
L’écosystème Steampipe s’est ensuite étendu avec des plugins pour de nombreux autres services, dont GitHub, Google Workspace, IMAP, Jira, LDAP, Shodan, Slack, Stripe et Zendesk. La jonction entre ces API est une superpuissance mieux prouvée par cet exemple qui joint les points de terminaison Amazon EC2 avec les vulnérabilités Shodan en seulement 10 lignes de SQL très basique.
sélectionner a.instance_id, des sports s.vulns depuis aws_ec2_instance a joint gauche shodan_host s sur a.public_ip_address = s.ip où a.public_ip_address n'est pas nul ; +---------------------+----------+---------------- ----+ | instance_id | ports | vulnérables | +---------------------+----------+---------------- ----+ | i-0dc60dd191cb84239 | nul | nul | | i-042a51a815773780d | [80,22] | nul | | i-00cf426db9b8a58b6 | [22] | nul | | i-0e97f373db42dfa3f | [22 111] | ["CVE-2018-15919"] | +---------------------+----------+---------------- ----+
Les fichiers sont aussi des API
Mais qu’est-ce qu’une API, vraiment ? Doit-il toujours impliquer des requêtes HTTP aux points de terminaison de service ? Plus largement, les API sont des sources de données qui existent également dans d’autres versions. Les pages Web sont encore souvent des API de facto. J’ai fait plus de scraping Web que je ne le pense au fil des ans et la compétence reste utile.
Les fichiers sont également des sources de données : fichiers de configuration (INI , YAML, JSON), fichiers d’infrastructure en tant que code (Terraform, CloudFormation), fichiers de données (CSV). Lorsque les plugins pour ces sources ont commencé à se joindre au mélange, Steampipe est devenu encore plus puissant.
Il y a d’abord eu le plug-in CSV, qui a déverrouillé toutes sortes de requêtes utiles. Considérez, par exemple, comment nous prétendons souvent que les feuilles de calcul sont des bases de données. Ce faisant, nous pouvons supposer qu’il existe une intégrité référentielle alors qu’il n’y en a pas vraiment. Si vous exportez des données de feuille de calcul au format CSV, vous pouvez utiliser SQL pour trouver ces hypothèses erronées. Et ce n’est qu’une des façons infinies que je peux imaginer d’utiliser SQL pour interroger le premier format de fichier au monde pour l’échange de données.
Puis vint le plugin Terraform, qui interroge les fichiers Terraform pour poser et répondre à des questions telles que : « Quels parcours ne sont pas cryptés ? »
sélectionner Nom, chemin depuis terraform_resource où type="aws_cloudtrail" et arguments -> 'kms_key_id' est nul ;
Utilisation de la table aws_cloudtrail_trail du plug-in AWS , nous pouvons poser et répondre à la même question pour l’infrastructure déployée, et renvoyer un ensemble de résultats que vous pourriez UNION avec le premier.
sélectionner Nom, arn comme chemin depuis aws_cloudtrail_trail où kms_key_id est nul ;
Idéalement, les réponses seront toujours les mêmes. Ce que vous avez dit doit être déployé, à l’aide de Terraform, doit correspondre à ce qui est réellement déployé si vous interrogez les API AWS. Dans le monde réel, bien sûr, la maintenance et/ou la réponse aux incidents peuvent entraîner une dérive de configuration. Étant donné une manière commune de raisonner sur une infrastructure définie et déployée, nous pouvons gérer une telle dérive par programmation.
Ceinture et bretelles
Pour l’infrastructure déployée, Steampipe fournit depuis longtemps une suite de mods qui couchent la sécurité et vérifications de conformité sur les tables étrangères dérivées de l’API. Le mod Conformité AWS, par exemple, fournit des repères et des contrôles pour vérifiez l’infrastructure déployée par rapport à onze normes et cadres, y compris CIS, GDPR, HIPAA, NIST 800-53 et SOC 2.
IDGAvec l’avènement du plugin Terraform, il est devenu possible de créer des mods complémentaires, comme Terraform AWS Compliance, qui fournit les mêmes types de vérifications pour l’infrastructure définie.
IDGCe que vous avez défini le mois dernier correspond-il à ce que vous avez déployé hier ? Une réponse satisfaisante nécessite la capacité de raisonner sur une infrastructure définie et déployée de manière commune et sans friction. SQL ne peut pas supprimer toutes les frictions, mais c’est un puissant solvant.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
