Sicherheit verbessern: wissen, wann IaC-Schwachstellen ignoriert werden sollten

Bei Sicherheitslücken gilt oft das Motto: „Schnapp sie dir alle“. In der Theorie klingt dieser Ansatz sinnvoll, in der Praxis ist er jedoch weniger effektiv und kostet Security- und Entwicklerteams häufig Zeit und unnötigen Aufwand. Effektiver ist es, Probleme zu analysieren und danach zu unterscheiden, welche für Ihr Unternehmen relevant und welche irrelevant sind. Letztere können Sie anschließend ignorieren. So können sich Ihre Teams auf kritische Probleme konzentrieren und die allgemeine Sicherheit Ihrer Anwendungen verbessern.

Snyk Infrastructure as Code (Snyk IaC) hilft IaC-Autoren nicht nur dabei, Sicherheitsprobleme in ihren Terraform-, Kubernetes- und CloudFormation-Codebasen zu finden, sondern ermöglicht es Ihnen jetzt auch, nicht relevante IaC-Schwachstellen zu ignorieren, wenn Sie snyk iac test ausführen. In diesem Blogbeitrag erläutere ich einige Situationen, in denen es sinnvoll sein kann, ein Problem nach dem Scannen Ihrer IaC-Konfigurationsdateien zu ignorieren, und zeige Ihnen, wie das funktioniert.

So konfigurieren Sie Snyk, um IaC-Schwachstellen zu ignorieren

Sicherheit sollte Teil des iterativen Softwareentwicklungszyklus sein und nicht separat oder erst „am Ende“ berücksichtigt werden. Die Snyk CLI wird häufig sowohl im Entwicklungszyklus als auch in CI-Pipelines eingesetzt, um Sicherheitsprobleme frühzeitig und regelmäßig zu erkennen. Unsere CLI wird von allen Produkten verwendet. Wenn Sie die Snyk CLI bereits zum Testen von Open-Source-Abhängigkeiten oder Containern nutzen, kennen Sie vielleicht schon die Möglichkeit, Probleme aus diesen Tests mithilfe der .snyk policy-Datei zu ignorieren. Auch Snyk IaC verwendet jetzt die .snyk-Policy-Datei, damit Sie IaC-Probleme einfach und automatisch ignorieren können.

Es gibt verschiedene Gründe, warum IaC-Autoren Probleme ignorieren möchten. Beispielsweise ist eine Sicherheitsregel für einen S3-Bucket, der für das öffentliche Internet zugänglich ist, für Sie möglicherweise nicht relevant, wenn Sie diesen Bucket bewusst zum Hosten öffentlicher Artefakte verwenden. Sicherheitsregeln zu erstellen, die für alle passen, ist schwierig! Sehen wir uns dieses Beispiel an.

Ein einfaches Beispiel zum Ignorieren

Hier sehen wir eine Terraform-Konfigurationsdatei, in der zwei S3-Buckets deklariert werden:

1resource "aws_s3_bucket" "blog" {
2  bucket = "blog"
3  acl = "public-read"
4}
5
6resource "aws_s3_bucket" "artifacts" {
7  bucket = "artifacts"
8  acl = "public-read"
9}

Wenn Sie in einem Verzeichnis mit dieser Datei snyk iac test ausführen, werden einige Probleme angezeigt. Dazu gehören zwei Fälle des Problems „öffentlich lesbar“, auf das wir uns konzentrieren. Hier ein teilweise geschwärzter Ausschnitt der Ausgabe:

1$ snyk iac test
2
3Testing terraform/s3/s3_cis.tf...
4
5Infrastructure as code issues:
6  ...
7
8  ✗ S3 Bucket is publicly readable [Medium Severity] [SNYK-CC-TF-18] in S3
9    introduced by input > resource > aws_s3_bucket[blog] > acl
10
11  ✗ S3 Bucket is publicly readable [Medium Severity] [SNYK-CC-TF-18] in S3
12    introduced by input > resource > aws_s3_bucket[artifacts] > acl
13
14...
15
16Tested terraform/s3/s3_cis.tf for known issues, found 10 issues

Wir können das Problem mithilfe der Snyk CLI ignorieren, indem wir snyk ignore --id=SNYK-CC-TF-18 --reason=’Blog bucket should be open ausführen. Dadurch wird eine .snyk-Policy-Datei mit folgendem Inhalt generiert, sofern sie noch nicht vorhanden ist:

1    # Snyk (https://snyk.io) policy file, patches or ignores known       vulnerabilities.
2version: v1.22.0
3    # ignores vulnerabilities until expiry date; change duration by modifying expiry date
4ignore:
5  SNYK-CC-TF-18:
6    - '*':
7        reason: Blog bucket should be open
8        expires: 2021-09-17T10:57:56.635Z
9        created: 2021-08-18T10:57:56.637Z
10patch: {}

Sie können den Grund und das Ablaufdatum ändern oder das Ablaufdatum bei Bedarf ganz entfernen. Weitere Informationen finden Sie in unserer Dokumentation zur Snyk-Funktion zum Ignorieren von Problemen und zur .snyk-Policy-Datei.

Wenn wir snyk iac test erneut ausführen, sehen wir, dass die Probleme mit der Kennzeichnung „öffentlich lesbar“ nicht mehr angezeigt werden.

Geltungsbereich für ignorierte Probleme festlegen

Betrachten wir jedoch den von uns angegebenen Grund für das Ignorieren dieses Problems – dass der blog-Bucket öffentlich zugänglich sein soll –, stellen wir fest, dass wir noch nicht ganz fertig sind. Wir möchten die Ignorierregel enger fassen, damit das Problem mit dem Artefakt-Bucket weiterhin angezeigt wird. Ändern wir zunächst die Regel *, die bedeutet „alle Fälle dieses Problems ignorieren“, in einen Dateipfad relativ zum Stammverzeichnis des Projekts:

1ignore:
2  SNYK-CC-TF-18:
3    - 'terraform/s3/s3_cis.tf > *':
4        reason: Blog bucket should be open
5        expires: 2021-09-17T10:57:56.635Z
6        created: 2021-08-18T10:57:56.637Z

So können wir Ignorierregeln auf einzelne Dateien beschränken. In diesem Beispiel treten jedoch beide Fälle des Problems „öffentlich lesbarer Bucket“ in derselben Datei auf. Fügen wir den Konfigurationspfad des Problems mit dem blog-Bucket anstelle des verbleibenden * ein:

1ignore:
2  SNYK-CC-TF-18:
3    - 'terraform/s3/s3_cis.tf > input > resource > aws_s3_bucket[blog] > acl':
4        reason: Blog bucket should be open
5        expires: 2021-09-17T10:57:56.635Z
6        created: 2021-08-18T10:57:56.637Z

Wenn wir snyk iac test erneut ausführen, sehen wir, dass der Fall der Schwachstelle „öffentlich lesbarer Bucket“ für unseren blog-Bucket erfolgreich ignoriert wird. Der Fall desselben Problems beim Artefakt-Bucket wird dagegen weiterhin angezeigt – ein Hinweis darauf, dass wir ihn beheben sollten!

1$ snyk iac test
2
3Testing terraform/s3/s3_cis.tf...
4
5Infrastructure as code issues:
6  ...
7
8  ✗ S3 Bucket is publicly readable [Medium Severity] [SNYK-CC-TF-18] in S3
9    introduced by input > resource > aws_s3_bucket[artifacts] > acl
10
11...
12
13Tested terraform/s3/s3_cis.tf for known issues, found 9 issues

Ändern wir die ACL des Artefakt-Buckets:

1resource "aws_s3_bucket" "blog" {
2  bucket = "blog"
3  acl = "public-read"
4}
5
6resource "aws_s3_bucket" "artifacts" {
7  bucket = "artifacts"
8  acl = "private"
9}

Wenn Sie jetzt snyk iac test ausführen, werden keine Fälle des Problems „öffentlich lesbarer Bucket“ mehr angezeigt – genau das möchten wir in diesem Beispiel erreichen. Anschließend können Sie die .snyk-Policy-Datei in Ihr Code-Repository einchecken, um diese Regeln unter Versionskontrolle zu stellen.

Starten Sie mit Snyk IaC

Laden Sie einfach die neueste Snyk CLI herunter, um diese Funktion sofort zu nutzen. Oder lesen Sie unsere Dokumentation mit einer Schritt-für-Schritt-Anleitung dazu, wie Snyk IaC Probleme mithilfe der Datei .snyk ignoriert.