安全なコードへの洞察

In der heutigen schnelllebigen Softwareentwicklungswelt müssen Unternehmen sowohl nach Geschwindigkeit als auch nach Sicherheit streben. Um dieses Gleichgewicht effektiv zu erreichen, müssen Entwickler nicht nur Sicherheitslücken identifizieren, sondern auch praktische Fähigkeiten zur sicheren Codierung entwickeln, die es ihnen ermöglichen, Fehler von Anfang an zu verhindern.

Aus diesem Grund freut sich Secure Code Warrior, unsere neue Integration mit anzukündigen Hacker One, ein führendes Unternehmen für offensive Sicherheitslösungen. Gemeinsam bauen wir ein leistungsstarkes, integriertes Ökosystem auf. HackerOne punktet wo Sicherheitslücken tatsächlich auftreten in realen Umgebungen, wodurch das „Was“ und „Wo“ von Sicherheitsproblemen aufgedeckt wird. Secure Code Warrior tritt dann ein, um Entwicklern die folgenden Funktionen zur Verfügung zu stellen „wie“ und „warum“ sollen diese Probleme an der Wurzel behoben werdenund stellt sicher, dass sie aus realen Erkenntnissen lernen und von Anfang an sichere Software und Anwendungen entwickeln. Diese Zusammenarbeit fördert eine wichtige Rückkopplungsschleife zwischen Sicherheitserkennung und den Fähigkeiten der Entwickler, was zu einem widerstandsfähigeren und sichereren Entwicklungszyklus führt.

Von der Entdeckung zur Meisterschaft: So funktioniert die Integration

Diese Integration operationalisiert Ihre HackerOne-Schwachstellendaten und wandelt die Ergebnisse in umsetzbare Lernmöglichkeiten um. Es handelt sich um einen einseitigen Ablauf, bei dem bestimmte in HackerOne-Berichten identifizierte Schwachstellentypen nahtlos mit relevanten, praktischen Lernmodulen in Secure Code Warrior verknüpft werden.

Der Prozess ist einfach:

• In der HackerOne-Plattform wurde eine Sicherheitslücke gemeldet.
• Wenn es für diesen Schwachstellentyp ein passendes Secure Code Warrior-Lernmodul gibt, erscheint ein Link direkt im HackerOne-Bericht. Wenn der Entwickler darauf klickt, wird er zu Schulungsinhalten weitergeleitet, die ihm helfen sollen, ähnliche Sicherheitslücken zu verstehen, zu beheben und in Zukunft zu verhindern.

• Um Entwickler dort zu treffen, wo sie arbeiten, können die Links zu denselben Lernmodulen außerdem direkt in bestehenden Workflows in Tools wie Jira, ServiceNow, GitHub, Linear, Azure DevOps, Asana und ClickUp über unterstützte Integrationen zugänglich gemacht werden.

Wichtigste Ergebnisse: Förderung der proaktiven Sicherheits- und Entwicklungsgeschwindigkeit

Bei dieser leistungsstarken Integration geht es nicht nur darum, Probleme zu beheben, sondern auch darum, Ihre Fähigkeiten auszubauen und Ihren Entwicklungszyklus zu transformieren. Durch die Operationalisierung der realen Schwachstellendaten von HackerOne in gezielte Secure Code Warrior-Lernpfade helfen wir Ihnen dabei:

• Weiterqualifizierung von Entwicklern: Ermöglichen Sie Ihren Teams, aus tatsächlichen Ergebnissen zu lernen, zu verstehen, warum Sicherheitslücken auftreten, und ähnliche Probleme zu vermeiden, indem Sie sichere Codierungspraktiken direkt in ihrem Arbeitsablauf beherrschen.
• Reduzieren Sie die Risikoexposition: Beseitigt proaktiv einen erheblichen Teil der eingeführten Sicherheitslücken (von 53%), was zu widerstandsfähigerer Software und einer stärkeren Sicherheitslage führt.
• Beschleunigen Sie die sichere Entwicklung: Verknüpfen Sie Erkenntnisse direkt mit der Ausbildung und fördern Sie schnellere, intelligentere Entwicklungszyklen, indem Sie die Mean-Time-To-Remediation (MTTR) um das Dreifache reduzieren und es den Sicherheitsteams ermöglichen, sich auf strategischere Initiativen zu konzentrieren.

Sind Sie bereit, den Kreislauf zwischen Sicherheit und Entwicklung zu schließen?
‍Diese Integration ist für Professional- und Enterprise-Kunden von HackerOne mit einem Business- oder Enterprise Secure Code Warrior-Plan verfügbar. Kontaktieren Sie uns, um mehr zu erfahren und loszulegen.
Erfahren Sie mehr von HackerOne über diese neue Integration und Partnerschaft hier.

Dieser Artikel erschien ursprünglich in SD-Zeiten. Es wurde hier aktualisiert und syndiziert.

‍

Die Überprüfung von Fähigkeiten war die meiste Zeit der Neuzeit ein Aspekt unseres Lebens. Sie verleiht uns Gültigkeit und öffnet Türen, die sonst nicht verfügbar wären. Autofahren ist zum Beispiel für die meisten ein wichtiger Übergangsritus, und es wird von uns erwartet, dass wir eine Reihe standardisierter Prüfungen bestehen, um zu bestätigen, dass wir eine viertausend Pfund schwere Maschine anvertrauen können, die in der Lage ist, über einhundert Meilen pro Stunde zu fahren. Fehler, insbesondere bei hoher Geschwindigkeit, können Sie dieses Privileg oder sogar ein Menschenleben kosten.

Aber was ist, wenn Autofahren für manche mehr als eine alltägliche Annehmlichkeit ist und es zu einem Eliteberuf wird? Eine Person kann ihre Weiterbildung fortsetzen und möglicherweise Formel-1-Fahrer werden, wo sie Maschinen bedienen darf, die schneller sind, als es ein Zivilist realistischerweise schaffen könnte, ohne dass bei hohen Geschwindigkeiten eine große Fehlerwahrscheinlichkeit besteht.

Vor diesem Hintergrund scheint es verblüffend, dass die meisten Entwickler, die an Code für kritische Infrastrukturen, Automobile, Medizintechnik und alles dazwischen arbeiten, dies tun, ohne zuvor ihre Sicherheitsfähigkeiten zu überprüfen. Warum müssen andererseits Entwickler mit Sicherheitskenntnissen, die wiederholt bewiesen haben, dass sie wissen, wie man Dinge sicher baut, wegen der vielen Sicherheitsschleusen in der Warteschlange mit allen anderen in der sich ständig verlangsamenden Entwicklungspipeline anstellen? Die Branche betrachtet das nicht als Versehen, es ist die Norm.

Aus umfangreichen Recherchen wissen wir, dass Die meisten Entwickler räumen der Sicherheit in ihrem Code einfach keine Priorität einund verfügen nicht über die regelmäßige Ausbildung, die erforderlich ist, um viele häufig auftretende Sicherheitslücken zu beheben. Sie sind in der Regel einer der Gründe, warum Sicherheit bei hoher Geschwindigkeit wie ein Hirngespinst erscheint, und viele Entwickler, die sich mit Sicherheit beschäftigen, haben das Gefühl, auf der Autobahn hinter einer Gruppe von Fahrschülern auf der langsamen Spur festzusitzen.

Trotzdem entwickelt sich die Sicherheitswelt langsam weiter, und es besteht eine steigende Nachfrage nach Entwicklern, die über verifizierte Sicherheitskenntnisse verfügen, die sofort loslegen können. Die der Biden-Administration Exekutivverordnung zur Verbesserung der Cybersicherheit des Landes fordert ausdrücklich die Bewertung der Sicherheitspraktiken der Anbieter — und ihrer Entwicklungskohorte — für alle Anbieter in der Software-Lieferkette der US-Regierung. Es liegt auf der Hand, dass die Bedeutung der Sicherheitskompetenzen von Entwicklern in den meisten Sektoren nur zunehmen wird, aber da kaum branchenübliche Bewertungen angeboten werden, wie können Unternehmen nachweisen, dass ihr Sicherheitsprogramm die nachweisbaren Sicherheitsfähigkeiten der Entwickler erweitert, sodass die Umsetzung nicht in die Knie gezwungen wird oder sicherheitsbewusste Entwickler daran gehindert werden, ihre Flügel auszubreiten?

Leistungsbasierte Zutrittskontrolle: Könnte das funktionieren?

Least-Privilege-Sicherheitskontrollen sind in vielen Unternehmen ein wichtiger Bestandteil. Dabei wird jeder Rolle im Rahmen ihrer Arbeit der Zugriff auf Software, Daten und Systeme nach dem Need-to-know-Prinzip zugewiesen, und nichts weiter. Diese Methode — insbesondere in Kombination mit Zero-Trust-Autorisierungsprinzipien — ist hilfreich, um das gesamte Ausmaß der Angriffsfläche abzufangen. Und wir sollten uns wirklich bewerben dieselbe Strategie für API-Berechtigungenund andere softwarebasierte Anwendungsfälle als Standard.

Die meisten von uns in der Sicherheitsbranche sind sich der Tatsache bewusst, dass Software die Welt verschlingt, und der eingebettete Systemcode, auf dem Ihre Heißluftfritteuse läuft, unterscheidet sich wirklich nicht von dem Code, der das Stromnetz am Laufen hält, was sein Potenzial angeht, ausnutzbar zu machen. Unser Leben und unsere kritischen Daten sind den Bedrohungsakteuren ausgeliefert, und jeder Entwickler muss verstehen, welche Möglichkeiten er hat, seinen Code zu schützen, wenn er richtig geschult ist. Es erfordert eine ernsthafte Verbesserung der Sicherheitskultur eines Unternehmens, aber für eine echte gemeinsame Verantwortung im DevSecOps-Stil benötigen Entwickler einen Grund, sich mehr um die Rolle zu kümmern, die sie spielen, und der vielleicht schnellste Weg, ihre Denkweise zu ändern, wäre, den Zugriff auf das Code-Repositorium an sichere Lernergebnisse beim Programmieren zu binden.

Nehmen wir zum Beispiel eine Organisation im BFSI-Bereich, stehen die Chancen gut, dass es hochsensible Repositorys geben wird, die Kundendaten oder wertvolle Informationen wie Kreditkartennummern speichern. Warum sollten wir dann davon ausgehen, dass jeder Techniker, dem Zugriff gewährt wurde, sicherheitsbewusst ist, strenge PCI-DSS-Anforderungen erfüllt und in der Lage ist, schnell und ohne Zwischenfälle Änderungen an der Hauptniederlassung vorzunehmen? Das mag zwar bei einigen der Fall sein, aber es wäre weitaus sicherer, den Zugriff auf diese empfindlichen Systeme zu beschränken, bis dieses Wissen bewiesen ist.

Die Herausforderung besteht darin, dass in den meisten Unternehmen die Einführung eines „License to Code“ -Szenarios mühsam und je nach Schulungslösung etwas zu manuell wäre, um jegliche Art von Security at Speed-Zielen zu unterstützen. Die richtige Kombination aus integrativer Schulung und Tools kann jedoch der Kern einer entwicklerorientierten, defensiven Sicherheitsstrategie sein.

Eine effektive Trainingsintegration ist nicht unmöglich.

Die Suche nach Weiterbildungslösungen für Entwickler, die sowohl die schnellen Geschäftsziele als auch ihren Arbeitsablauf ergänzen, ist die halbe Miete, aber wenn wir uns ins Zeug legen, um Compliance-Schulungen zu vermeiden, die „einmalig“ sind, ist der einzige Weg, um eine spürbare Reduzierung der Sicherheitslücken auf Codeebene zu erzielen. Und für Entwickler, die sich erfolgreich beweisen? Nun, die Welt des Programmierens liegt ihnen zu Füßen, und sie müssen sich nicht durch Sicherheitskontrollen behindern lassen, die davon ausgehen, dass sie sich nicht in den Grundlagen zurechtfinden.

Praktische Fähigkeiten, die sich nahtlos in die Entwicklungsumgebung integrieren lassen, bieten den nötigen Kontext, damit Ingenieure sichere Programmierkonzepte wirklich verstehen und anwenden können. Dieselben Integrationen können verwendet werden, um den Zugriff auf kritische Systeme effektiv zu verwalten und sicherzustellen, dass diejenigen, die ihre Lernergebnisse übertreffen, ungehindert an den sensiblen Aufgaben mit der höchsten Priorität arbeiten. Es erleichtert auch die Implementierung von Prämien und Anerkennungen und stellt sicher, dass Entwickler mit Sicherheitskenntnissen in ihrer Kohorte als ehrgeizig angesehen werden.

Wie bei vielen Dingen im Leben ist das Glück mit den Mutigen, und den Status Quo zu brechen, um einen sofort einsatzbereiten Ansatz zur Überprüfung der Fähigkeiten von Entwicklern zu verfolgen, ist genau das, was wir brauchen, um die Standards für akzeptable Codequalität von morgen zu verbessern, ohne an Geschwindigkeit einzubüßen.

Bedrohungen der Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Es ist so schlimm geworden, dass es fast unmöglich geworden ist, nach der Bereitstellung von Programmen mit ihnen Schritt zu halten. Stattdessen befürworten kluge Unternehmen das Konzept der Infrastruktur als Code, bei dem Entwickler zur Entwicklung sicherer Anwendungen beitragen, während sie noch in der Entwicklung sind. In dieser Serie geht es darum, Sie auf die Sicherheit vorzubereiten, damit Sie die Schritte verstehen, die Sie als Entwickler ergreifen können, um mit der Implementierung einer sicheren Infrastruktur als Code in Ihrem eigenen Unternehmen zu beginnen.

Sicherheitsfehlkonfigurationen, insbesondere solche mit falschen Berechtigungen, treten am häufigsten auf, wenn ein Entwickler einen neuen Benutzer erstellt oder die Erlaubnis für eine Anwendung als Tool erteilt, um eine Aufgabe zu erledigen. Dies könnte beispielsweise geschehen, um Informationen aus einer Datenbank zu sammeln. Wenn die Berechtigungen für den neuen Benutzer jedoch zu hoch eingestellt sind oder nicht standardmäßig für die jeweilige Aufgabe konfiguriert sind, kann dies zu einer schwerwiegenden Sicherheitslücke im Code führen.

Warum testen Sie nicht gleich Ihre Fähigkeiten, bevor wir darauf eingehen? Versuchen Sie, einige Sicherheitslücken mit falschen Zugriffsrechten zu finden und zu beheben:

Wie hast du dich geschlagen? Lass uns etwas tiefer graben:

Einem Benutzer oder einer Anwendung volle Berechtigungen zu erteilen oder sich einfach nicht die Mühe zu machen, zu definieren, was der neue Benutzer erreichen soll und welche Verhaltensweisen eingeschränkt sind, ist sicherlich der schnellste Weg, um neuen Code zu implementieren. Und wenn alles perfekt läuft, nutzt die Anwendung diese Berechtigungen, um die ihr zugewiesene Aufgabe zu erfüllen. Die Gefahr besteht darin, dass ein Hacker diesen Prozess entdeckt und dann den Benutzer gefährdet. Obwohl der Benutzer für eine bestimmte Funktion für eine bestimmte Anwendung geschaffen wurde, kann ein Angreifer, wenn er kompromittiert wird, andere Anwendungen, Daten oder sogar das Netzwerk gefährden.

Wie werden Sicherheitsfehlkonfigurationen ausgenutzt?

Um die Gefahr zu veranschaulichen, schauen wir uns an, wie eine häufige Aufgabe manchmal in der Docker-Cloud-Umgebung codiert wird. Nehmen wir an, ein Entwickler verwendet den Prometheus MySQL Exporter-Dienst, um Informationen aus einer Datenbank zu sammeln. Der einfachste Weg, dies zu ermöglichen, besteht darin, dem Exporteur die Erlaubnis zu erteilen, auf die Datenbank zuzugreifen. Der Code könnte also etwa so aussehen:

VON mysql:latest
KOPIEREN. /scripts/create_users.sh /docker-entrypoint-initdb.d/
BENUTZER 999
BENUTZER-EXPORTER@% IDENTIFIZIERT DURCH $EXPORTER_PASSWORD;
ALLES AUF *.* DEM EXPORTEUR@% GEWÄHREN;
GEWÄHREN SIE SELECT AUF performance_schema.* AN exporter@%;

Dies würde es sicherlich ermöglichen, dass der Exporteur seine Aufgabe erfüllen könnte. Da die Berechtigungen jedoch nicht definiert sind, kann der Exporteur tatsächlich fast alles tun. Offensichtlich würde der Exporteur selbst niemals außerhalb seiner programmierten Verhaltensweisen handeln. Aber was würde passieren, wenn ein Angreifer in der Lage wäre, den Exportservice zu kompromittieren? In diesem Fall könnte der Angreifer alle Arten von nicht autorisierten Aufgaben mit dem SQL-Dienst ausführen, da ihm die vollen Berechtigungen erteilt wurden.

Sicherung und Beseitigung unzulässiger Berechtigungen

Auch hier wenden wir uns dem Konzept der Infrastruktur als Code zu. Wenn Sie die Sicherheit Ihrer Anwendungen bei deren Erstellung einprogrammieren, wird das Netzwerk in Bezug auf Cybersicherheit insgesamt immer auf einer viel besseren Grundlage stehen.

Wenn ein Entwickler im Docker-Beispiel von oben möchte, dass der Prometheus MySQL Exporter eine Datenbank abfragen kann, kann er dies sicherer machen, indem er definiert, was er tun darf. Ein gutes Beispiel dafür wäre:

VON mysql:latest
KOPIEREN. /scripts/create_users.sh /docker-entrypoint-initdb.d/
BENUTZER 999
BENUTZER-EXPORTER@% IDENTIFIZIERT DURCH $EXPORTER_PASSWORD;
PROZESS GEWÄHREN, REPLIKATIONSCLIENT AUF *.* AN DEN EXPORTIERER@%;
GEWÄHREN SIE SELECT AUF performance_schema.* AN exporter@%;

In diesem Fall hat der für den Prometheus MySQL Exporter-Dienst konfigurierte MySQL-Benutzer nur eingeschränkte Berechtigungen für den MySQL-Dienst. Insbesondere sind nur PROCESS- und REPLICATION CLIENT-Rechte zulässig. Dies würde verhindern, dass ein böswilliger Benutzer einen kompromittierten Prometheus MySQL Exporter-Dienst ausnutzt.

Durch das Einschränken von Berechtigungen auf Codeebene kann sichergestellt werden, dass Benutzer und Anwendungen nur über genügend Berechtigungen für die jeweilige Aufgabe verfügen. Und das kann einen großen Beitrag dazu leisten, Ihre Netzwerke zu schützen und das Konzept der Infrastruktur als Code umzusetzen.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere unseren Showcase der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

セキュアなIaC（Infrastructure as Code）を組織に導入するための手順を知りたい開発者の方は、ぜひ参考にしてみてください。本章は、IaCシリーズの次の章で、IaCセキュリティのベスト・プラクティスのレベルアップを目的としています。

始める前に、前回の課題はどうだったでしょうか？安全でない暗号をマスターした人は、詳細を見る前に、不十分なトランスポート層保護をどうするか見てみましょう。

もっと勉強して満点を目指しませんか？読んでみてください。

前回の記事では、アプリケーションやプログラムに保存されている重要なデータや個人情報を保護するために、安全な暗号化を行うことの重要性についてお話ししました。強力な暗号化があれば、それは完璧な最終防衛ラインとして機能します。たとえ攻撃者がデータを盗むことができたとしても、強力に暗号化されていれば、そのファイルの中に閉じ込められた情報は守られます。

しかし、静止状態のデータを保護することは、完全なデータ防衛の一部分に過ぎません。有効なユーザーが保護されたデータにアクセスする必要がある場合は、データを送信する必要があります。また、アプリケーションは、全体的なワークロードの一環として、他のプログラムとデータを共有することもあります。トランスポート層が保護されていないと、外部からの盗み見や内部からの不正な閲覧に対して脆弱になります。このように、トランスポート層の保護が不十分であると、深刻な問題が発生します。

これは一般的な問題です。OWASPセキュリティ組織は、不十分なトランスポート層保護に関するページを設けています。

なぜトランスポートレイヤーの保護が不十分だと危険なのか？

トランスポート層を十分に保護していない場合、熟練したハッカーは、中間者攻撃などの手法を用いて、ユーザとアプリケーションの間を流れる情報を比較的容易に傍受することができます。

例えば、Docker環境でNginxサービスをデプロイした場合の例です。

services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target:/etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy:*default-restart_policy
resources:*default-resources_policy

Nginxのサービス設定では、接続の暗号化や保護が行われないため、リンクを通じてやり取りされるすべての情報は、さまざまな攻撃やスヌーピングに対して脆弱になります。

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

多くの場合、トランスポート層を誰かが盗み見ているかもしれないという最初のシグナルは、盗まれた大量のユーザーパスワードがその後の攻撃に使用されたときです。安全ではないトランスポート層を経由して、顧客情報、財務記録、企業の重要な秘密などの他のデータが盗まれた場合は、侵害されたことに気づかないこともあります。

保護が必要なのは、ユーザーとアプリケーションの間のトランスポート層だけではありません。バックエンドでは、多くのアプリケーションが相互に通信したり、ワークフローチェーンの遠くにあるサーバと通信したりしています。これらの内部通信は通常、外部からの盗聴に対して脆弱ではありませんが、ネットワークへのアクセスは許可されていても、高度に保護された機密情報の閲覧を許可されていないユーザーにデータがさらされる可能性があります。

トランスポート層を適切に保護し、データを完全に保護する

トランスポートレイヤーの保護は、アプリケーションの作成中に行うのがベストです。このプロセスは、安全なバックエンド・インフラストラクチャを持つことから始まる。Web サイトでは、すべての作業を HTTPS で行う必要があります。HTTP と HTTPS のインフラを混在させてはならない。また、安全でない HTTP リクエストを自動的に HTTPS インフラに転送するように設定すべきである。

上記の例では、トランスポート層を保護する適切な方法は次のようになります。

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

この例では、Nginx サービスとの接続はすべて強力に暗号化されます。Nginx の設定のサーバーセクションにはlisten 8443 ssl のみが含まれており、SSL による接続の保護を強制しています。

インサイダーの脅威からデータを守るために、開発者は TLS 1.2 のような強力なトランスポート層暗号化プロトコルを採用すべきです。TLS 1.2またはそれに相当するプロトコルを導入したら、SSL v2のような弱いプロトコルはインフラから完全に削除し、自動的に使用できないようにする必要があります。

また、アプリケーションの保護は、静止データとトランスポート層の両方が十分に保護されて初めて完全なものとなることを常に念頭に置いてください。このようにして、内部および外部の許可されたユーザーに流れるデータの完全なエンド・ツー・エンドの保護を保証することができます。
Secure Code Warriorブログページでは、この脆弱性に関する詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守る方法について紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。

このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。

お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。

セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？

この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。

しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。

# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True

この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。

デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。

無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消

この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。

# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False

現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。

無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。

その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

Im Gegensatz zu den meisten Sicherheitslücken in den Top Ten der OWASP-API geht es bei unsachgemäßem Asset-Management nicht speziell um Codierungsfehler. Stattdessen handelt es sich bei dieser Sicherheitslücke eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs noch lange bestehen bleiben, nachdem sie durch neuere, sicherere Versionen hätten ersetzt werden sollen. Sie kann auch auftreten, wenn APIs, die sich noch in der Entwicklung befinden, der Produktionsumgebung ausgesetzt sind, bevor sie vollständig gegen Bedrohungen geschützt sind.

Diese Sicherheitsanfälligkeit ist aufgrund des Aufkommens von Microservices und Cloud Computing besonders schwierig zu handhaben. In dieser Umgebung können neue Dienste schnell bereitgestellt werden, um einen vorübergehenden Bedarf zu decken, und dann vergessen und niemals außer Betrieb genommen werden. Wenn die älteren APIs weiterhin mit der Produktionsumgebung verbunden bleiben, kann dies das gesamte Netzwerk gefährden.

Willst du eine spielerische Herausforderung zu diesem Sicherheitsproblem ausprobieren? Treten Sie ein in unsere Arena: [Fangen Sie hier an]

Wie wirken sich unsachgemäße Fehler in der Vermögensverwaltung auf APIs aus?

Der Fehler in der unsachgemäßen Vermögensverwaltung ist ein Produkt der Neuzeit. Unternehmen, die mit der Geschwindigkeit ihrer Geschäftstätigkeit Schritt halten, können manchmal täglich Hunderte oder Tausende von Diensten und Microservices anbieten. Dies geschieht häufig schnell und ohne die Erstellung einer Begleitdokumentation oder einer Erklärung, wofür die zugehörigen APIs verwendet werden, wie lange sie benötigt werden oder wie wichtig sie sind. Dies kann schnell zu einer Vielzahl von APIs führen, die im Laufe der Zeit unzähmbar werden könnten, insbesondere wenn es keine pauschalen Richtlinien gibt, die definieren, wie lange APIs existieren können.

In dieser Umgebung ist es sehr wahrscheinlich, dass einige APIs verloren gehen, vergessen oder nie außer Betrieb genommen werden.

Manchmal sind auch Benutzer schuld, die die Erlaubnis haben, neue Dienste außerhalb des normalen Prozesses zu erstellen. Zum Beispiel könnte eine Marketinggruppe einen Service zur Unterstützung einer bevorstehenden Veranstaltung wie einer Produkteinführung erstellen und ihn dann nach Abschluss der Veranstaltung nie wieder abschalten. Jemand, der sich diesen Service und die zugehörigen APIs später ansieht, hat möglicherweise keine Ahnung, warum sie existieren, und wenn es keine Dokumentation gibt, könnte es ein Rätsel bleiben. Sie fühlen sich möglicherweise nicht wohl dabei, diese APIs aus der Produktionsumgebung zu entfernen oder sie sogar auf neuere Versionen zu aktualisieren, weil sie keine Ahnung haben, wie wichtig sie sind oder was sie tun.

Die Sicherheitsanfälligkeit wird gefährlich, da sich die Sicherheit von APIs in Frameworks im Laufe der Zeit verbessert. Ein Forscher könnte eine Sicherheitslücke entdecken, oder es könnten zusätzliche Sicherheitsmaßnahmen hinzugefügt werden, um eine immer beliebter werdende Art von Angriff abzuwehren. Ältere APIs können für diese Angriffe anfällig bleiben, sofern sie nicht aktualisiert werden. Daher suchen Hacker häufig nach ihnen oder verwenden automatisierte Tools, um sie ausfindig zu machen.

In einem realen Beispiel von OWASP hat ein Unternehmen seine APIs aktualisiert, mit denen Benutzerdatenbanken durchsucht werden, um einen kritischen Fehler zu beheben. Aber sie haben versehentlich die alten APIs an Ort und Stelle belassen.

Ein Angreifer bemerkte, dass der Speicherort der neuen API etwa so lautete (api.criticalservice.com/v2). Indem sie die URL durch (api.criticalservice.com/v1) ersetzten, konnten sie stattdessen die alte API mit der bekannten Sicherheitslücke verwenden. Dadurch wurden letztendlich die persönlichen Daten von über 100 Millionen Benutzern preisgegeben.

Beseitigung unsachgemäßer Mängel in der Vermögensverwaltung

Die einzige Möglichkeit, den Fehler in der Verwaltung unsachgemäßer Ressourcen in Ihrer Umgebung zu beseitigen, besteht darin, ein enges Inventar aller APIs, ihrer Verwendungen und Versionen zu führen. Dies sollte mit einer Bestandsaufnahme der vorhandenen APIs beginnen und sich auf Faktoren wie die Umgebung konzentrieren, in der sie bereitgestellt werden sollten, z. B. in der Produktion oder Entwicklung, wer Netzwerkzugriff auf sie haben sollte und natürlich auf ihre Version.

Sobald dies abgeschlossen ist, müssen Sie einen Prozess implementieren, bei dem Dokumentation automatisch zu allen neuen APIs oder Diensten hinzugefügt wird, die erstellt werden. Dies sollte alle Aspekte der API umfassen, einschließlich der Ratenbegrenzung, der Art und Weise, wie Anfragen und Antworten verarbeitet werden, der gemeinsamen Nutzung von Ressourcen, den Endpunkten, zu denen sie eine Verbindung herstellen kann, aller relevanten Richtlinien, die gelten, sowie alles andere, was für eine spätere Überprüfung erforderlich ist. Sie sollten auch vermeiden, jemals APIs außerhalb der Produktionsumgebung oder APIs aus der Entwicklungsumgebung in der Produktion zu verwenden. Erwägen Sie auch, APIs zeitlich zu begrenzen, wenn ihre fortgesetzte Verwendung von ihren Eigentümern begründet werden muss, um eine automatische Außerbetriebnahme zu verhindern.

Wenn neue Versionen aktiver APIs verfügbar werden, führen Sie eine Risikobewertung durch, um festzustellen, ob Sie ein Upgrade durchführen sollten und wie dieser Prozess ablaufen sollte, um eine Unterbrechung der Produktionsumgebung zu vermeiden. Sobald Sie zu den neuen APIs migriert haben, entfernen Sie die alten vollständig aus der Umgebung.

Wenn Sie all dies tun, können Sie verhindern, dass die Sicherheitslücke bei der unsachgemäßen Vermögensverwaltung Ihrem Unternehmen, Ihren Benutzern oder Ihrem Netzwerk schadet. Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

‍

Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrem Weg zur IaC-Sicherheit zu helfen.

Hast du die Herausforderungen gespielt? Was ist dein bisheriges Ergebnis? Bevor wir beginnen, schauen wir uns an, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:

Hast du noch etwas zu tun? Lesen Sie weiter:

Das anfällige Verhalten, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und Ressourcen bietet viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar ihren fertigen Code in Repositorys wie GitHub einzubringen, um von anderen verwendet zu werden, die Schwierigkeiten haben, ein Programm oder eine App richtig funktionieren zu lassen. Die Verwendung von abgeschlossenem Code zur Steuerung von Programmfunktionen erspart Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.

Die Verwendung von Codefragmenten aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein hohes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen eine der häufigsten Arten, mit denen sich sowohl größere als auch kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Sicherheitslücken versehentlich von ihren Urhebern verursacht. Es gab auch Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann geteilt, in der Hoffnung, Opfer zu verführen, die ihn dann in ihre Anwendungen einfügen.

Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?

Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung konfigurieren, die er gerade entwickelt. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, führen sie eine Google-Suche durch und finden jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Obwohl der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn einer neuen Anwendung hinzuzufügen. Dies kann in der Docker-Umgebung mit zwei Zeilen erfolgen:

FÜHREN SIE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Jetzt ruft das Docker-Image die Konfigurationsdatei des Drittanbieters dynamisch ab. Und selbst wenn die Datei getestet wurde und zu dem Zeitpunkt für in Ordnung befunden wurde, bedeutet die Tatsache, dass der Zeiger jetzt in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit besteht. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die gemeinsam genutzte Konfigurationsdatei die Anwendung anweisen, ganz anders als beabsichtigt zu arbeiten, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.

Eine bessere Möglichkeit, gemeinsam genutzte Ressourcen zu nutzen

Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher ausgeführt wird. Achten Sie bei der Bewertung von externem Code auf eine mögliche Verwendung darauf, Komponenten nur über sichere Links aus offiziellen Quellen zu beziehen. Und selbst dann sollten Sie niemals auf eine externe Quelle verlinken, um diesen Code abzurufen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte der genehmigte Code in eine sichere Bibliothek gebracht und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also so aussehen:

KOPIERE src/config/default-ssl.conf /etc/apache2/sites-available/

Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf einer lokalen Kopie dieser Dateien beruhen. Dadurch wird verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.

Zusätzlich zur Verwendung einer sicheren Codebibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um die Komponenten während des gesamten Softwarelebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mithilfe von Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Entfernen Sie abschließend alle ungenutzten oder unnötigen Abhängigkeiten und Funktionen, die mit dem externen Code mitspielen könnten.

Wenn Entwickler diese Schritte befolgen, können sie externe Ressourcen sicherer nutzen, ohne versehentlich Sicherheitslücken in ihren Anwendungen und ihrem Code zu verursachen.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der IaC-Herausforderungen auf der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Daten sind das Lebenselixier von Unternehmen. Es sind die grundlegenden Informationen, die zum Überleben, zum Geldverdienen und zur Erbringung von Dienstleistungen für ihre Kunden benötigt werden. In dieser zunehmend digital ausgerichteten Gesellschaft tragen Entwickler eine immense Verantwortung als Verwalter dieser wertvollen Informationen. Wenn Entwickler vertrauliche Daten nicht schützen, fällt das Unternehmen der unsicheren kryptografischen Speicherung zum Opfer.

Schauen wir uns an, wie Sie Daten sicher speichern können und was passieren kann, wenn Sie dies nicht tun.

Unsicheren kryptografischen Speicher verstehen

Wenn Angreifer Zugriff auf ein System erhalten, sind sie in der Regel auf der Suche nach wertvollen Daten. Sie wissen schon — die Art von Daten, die verwendet werden können, um das Konto einer anderen Person zu übernehmen oder um einen weiteren Angriff auszuführen. Manchmal werden diese Daten einfach auf dem Schwarzmarkt gegen schnelles Geld verkauft.

Unsicherer kryptografischer Speicher ist keine einzige Sicherheitslücke wie SQL Injection oder XSS. Dies ist eine Folge davon, dass die Daten, die Sie schützen sollten, nicht so geschützt werden, wie Sie sie schützen müssen.

Sensible Informationen müssen geschützt werden. Wenn Sie Passwörter und Kreditkarteninformationen im Klartext speichern, spielen Sie Russisches Roulette mit deinem Unternehmen.

Wenn ein Hacker in Ihre Datenbank einbricht und Daten stiehlt mit SQL-Injektion, XML-Injektion oder irgendein anderer Angriff, sie werden alles haben. Wenn Sie Ihre Daten jedoch verschlüsseln, wird es für sie viel schwieriger sein, sie wirklich zu nutzen.

Es ist wichtig zu beachten, dass Verstöße nicht immer das Ergebnis eines böswilligen Außenstehenden sind. Ein böser Insider kann auch problemlos Daten stehlen, wenn sie nicht verschlüsselt sind. Die Mitarbeiter Ihres Unternehmens müssen nicht alles in der Datenbank sehen, und unzureichende Zugriffskontrollen oder offengelegte sensible Daten können zu regelrechtem Diebstahl führen.

Denken Sie auch daran, dass nicht alle Verschlüsselungen gleich sind. Die Verwendung falscher kryptografischer Algorithmen ist genauso gefährlich, wie sie überhaupt nicht zu verwenden. Bekannte schwache Algorithmen werden versierten Angreifern wenig Widerstand bieten.

Warum unsicherer kryptografischer Speicher gefährlich ist

Viele Unternehmen sind gefährdet durch eine andere Sicherheitslücke (wie SQL Injection) und am Ende nicht in der Lage sind, die gestohlenen Daten zu verbergen. Das macht eine schreckliche Situation noch schlimmer.

• Adult Friend Finder wurde gehackt, wodurch 412 Millionen Konten durchgesickert sind. Die Passwörter für die Konten wurden mit dem schwachen SHA-1-Hashing-Algorithmus geschützt. Sie konnten innerhalb eines Monats leicht von Angreifern geknackt werden.
• Uber wurde gehackt, wobei 57 Millionen Benutzerdaten und 600.000 Fahrerdatensätze durchgesickert wurden. Persönliche Daten gingen verloren. Es ist passiert, weil das GitHub-Konto von Uber ein Repository hatte, in dem der Benutzername und das Passwort des AWS-Kontos von Uber veröffentlicht wurden... keine gute Idee. Die Bewertung von Uber fiel um 20 Milliarden US-Dollar, was hauptsächlich auf diesen Verstoß zurückzuführen ist.
• Das PlayStation Network von Sony wurde gehackt, wodurch 77 Millionen Konten durchgesickert wurden. 12 Millionen der Konten enthielten unverschlüsselte Kreditkarteninformationen. Sony legte später eine Sammelklage in Höhe von 15 Millionen US-Dollar wegen des Verstoßes bei.

Es gibt eindeutig schwerwiegende Folgen, wenn sensible Daten nicht ordnungsgemäß gespeichert werden.

Sony wurde verklagt, was eine erhebliche Strafe darstellt. Aber selbst wenn Sie nicht verklagt werden, kann der Ruf- und Regulierungsschaden für ein Unternehmen katastrophal sein.

Beseitigen Sie unsicheren kryptografischen Speicher

Wie können Entwickler verhindern, dass Datenschutzverletzungen wie die oben genannten passieren?

Der erste Schritt besteht darin, herauszufinden, welche Daten überhaupt verschlüsselt werden müssen. Schließlich sind nicht alle Daten gleich. Kategorisieren Sie Ihre Datenund verwenden Sie dann gegebenenfalls Verschlüsselung.

Im Allgemeinen müssen persönliche Daten wie Sozialversicherungsnummern, Passwörter und Kreditkartendaten geschützt werden. Je nach Art Ihres Unternehmens müssen Sie möglicherweise Gesundheitsdaten oder andere Informationen, die als privat gelten, schützen.

Sobald Sie wissen, welche Daten geschützt werden müssen, besteht der nächste Schritt darin, die richtigen Tools zu verwenden, um deren Sicherheit zu gewährleisten. Im Allgemeinen ist es gut, sich an kryptografische Algorithmen zu halten, die sich im Laufe der Zeit bewährt haben und als stark gelten.

Egal was passiert, schreiben Sie keine eigenen kryptografischen Funktionen. Sie enthalten wahrscheinlich Fehler, die Angreifer nutzen können, um die Verschlüsselung zu knacken.

Um Daten wie Sozialversicherungsnummern oder Kreditkartendaten zu verschlüsseln, verwenden Sie AES. Es gibt verschiedene Betriebsmodi für AES. Ein zum Zeitpunkt des Schreibens dieses Artikels dringend empfohlener Modus ist Galois-/Zählermodus (GCM). Ein weiterer Tipp ist, sicherzustellen, dass für Bibliotheken, in denen Sie aufgefordert werden, eine Art von Polsterung auszuwählen, kein Padding verwendet wird.

Verwenden Sie für Passwörter einen Hash-Algorithmus, um Passwörter zu hashen, da Hashes nicht rückgängig gemacht werden können. Bei einem stark gehashten Wert kann ein Angreifer den Originaltext, der den Wert erstellt hat, nicht abrufen. Argon 2und Bcryptgelten als solide Wahl für das Hashing von Passwörtern. Denken Sie daran, das Passwort vor dem Hashing immer mit einem Zufallswert zu „salzen“, damit keine zwei Hashes für dasselbe Passwort gleich sind.

Diese Funktionen werden für alle wichtigen Programmiersprachen/Frameworks implementiert sein. In der Dokumentation für Ihre spezifische Sprache oder Ihr Framework finden Sie Informationen darüber, wie Sie sie effektiv verwenden können.

Die Generierung, Speicherung und Verwaltung von Schlüsseln sind wichtige Bestandteile der Kryptografie. Schlecht verwaltete Schlüssel können offengelegt und zur Entschlüsselung Ihrer Daten verwendet werden. Einige Frameworks helfen bei der Schlüsselverwaltung, wie z. B. Die Datenschutz-API von ASP.NET. Allgemeine Best Practices für die Schlüsselverwaltung finden Sie unter Spickzettel von OWASP.

Durch die sichere Speicherung Ihrer Daten verhindern Sie kostspielige, peinliche Datenschutzverletzungen. Im schlimmsten Fall, wenn ein Angreifer in der Lage ist, Ihre Daten zu stehlen, wird es für ihn viel schwieriger sein, sie zu sehen oder für schändliche Zwecke zu verwenden.

Verstecken Sie Ihre Daten vor aller Augen

Lassen Sie uns kurz überprüfen, wie Sie Ihre Daten schützen können:

• Kategorisieren Sie Ihre Daten, damit Sie wissen, was geschützt werden muss
• Verwenden Sie starke, branchenweit geprüfte Algorithmen zur Verschlüsselung sensibler Daten
• Speichern Sie Ihre Passwörter mit starken Einweg-Hashes

Um das Thema weiter zu studieren, schauen Sie sich unsere Ressourcen zum Lernen. Wenn du bereit bist, dich einzuarbeiten und zu üben, probiere unsere Plattform aus in Ihrer bevorzugten Sprache. Wir decken eine Menge ab!

Mit diesen Tools können Sie verhindern, dass Ihre Daten gestohlen werden, und verhindern, dass Ihr Unternehmen Geld verliert und seinen Ruf schädigt.

Bereit, unsicheren kryptografischen Speicher sofort zu finden und zu reparieren? Begib dich in die Arena und teste deine Fähigkeiten [starte hier]

セキュアなインフラストラクチャ・アズ・コードを組織内に導入する際、あなたはどのように取り組んでいますか？多少の学習曲線はあるかもしれませんが、ロープを学ぶことは、自分のスキルセットをレベルアップさせ、同僚の中で際立った存在になり、より多くのエンドユーザーのデータを安全に保つための大きなチャンスとなります。

最新の「Coders Conquer Security」シリーズの次の章を始める前に、機密データ保存の脆弱性をゲーム化した課題をプレイしていただきたいと思います。今すぐプレイして、Kubernetes、Terraform、Ansible、Docker、CloudFormationの中から選んでください。

どうでしたか？もし、あなたの知識にちょっとした工夫が必要なら、ぜひ読んでみてください。

最近のコンピュータ・セキュリティでは、ほとんどの場合、パスワードが使われています。二要素認証や生体認証など、他のセキュリティ方法を採用していても、ほとんどの組織では、保護の一要素としてパスワードによるセキュリティを採用しています。多くの企業では、パスワードを独占的に使用しています。

私たちはパスワードを多用しており、その作成方法にはルールがあるほどです。これは、ブルートフォース攻撃や不正な推測に対する脆弱性を減らすためのものです。もちろん、未だに脆弱なパスワードを使用している人もいて、NordPass社の最近のレポートでもそれが証明されています。2020年になっても、人々が最も重要な資産を守るために、12345や、chocolate、password、godなどの推測可能な言葉を使っているとは信じがたいことです。

強力なパスワードの使用を望まない人は常にいますが、ほとんどの専門機関では、ユーザーに一定の方法でアクセスワードやフレーズを作成することを義務付けています。パスワードは8文字以上で、大文字と小文字の両方で構成され、少なくとも1つの数字と特殊文字が必要であるというルールは、もう誰もが知っていることでしょう。

悪いことに、ユーザーが最強のパスワードを作るためのルールを守ったとしても、それがすべて平文で保存されていたら意味がありません。12345というパスワードは、ハッカーがパスワードファイル全体を読み取ることができれば、Nuts53!SpiKe&Dog12と同じくらい悪いものになってしまいます。

なぜパスワードを平文で保存することが危険なのか？

パスワードを平文で保存することは、システムとユーザーの両方を危険にさらすことになるため、よくありません。ハッカーがシステムへのアクセスに使われたすべてのパスワードを見つけて読み取ることができれば、大惨事になることは明らかです。ハッカーは、管理者資格を持つユーザーを見つけるだけで、システムやサイト全体を危険にさらすことができます。また、適切なユーザー名とパスワードを使用しているため、内部のセキュリティでは侵入を発見できなかったり、被害が拡大してからでは間に合わなかったりします。

平文で保存されたパスワードを攻撃者が簡単に盗めるようになると、多くの人がパスワードを使い回してしまうため、ユーザーにとっても不都合が生じます。パスワードの作成が非常に難しくなったため、多くの人が覚えているパスワードを複数のサイトで使いまわしています。攻撃者がパスワードファイルを侵害した場合、ほぼ確実に同じ名前とパスワードを使って他のシステムにアクセスしようとするため、ユーザーは二次的な犯罪に巻き込まれる危険性が高くなります。

誤ってパスワードをプレーンテキストで保存してしまったり、それが将来的に大きな問題を引き起こす可能性があることに気づかなかったりすることは比較的簡単です。例えば、以下のコードはTerraformテンプレートを使ってAWSリソースを定義する際に、パスワードを保存するためによく採用される方法です。

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}。

この例では、AWSのMySQLデータベースインスタンスを管理するためのパスワードが平文で保存されています。つまり、ソースコードリポジトリにアクセスできる人なら誰でも読めてしまうし、コピーもできてしまうのです。

パスワードの保護は、フレームワークによって異なりますが、保護方法はどのプラットフォームにも存在します。例えば、MySQLのパスワードは、AWS Secrets Managerのような安全なストレージに保存することができます。

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}。

この例では、TerraformテンプレートはAWS Secrets Managerサービスからパスワードを取得し、テンプレートファイルに平文で保存されることはありません。

平文保存を避けてパスワードを保護する

パスワードは王国の鍵であり、決して平文で保管すべきではありません。たとえ組織の内部の人間であっても、保護されていないパスワードの大規模な保管場所にアクセスすべきではありませんし、このようなことはビジネスプロトコルとして認められるべきではありません（最近では、暗号化された認証情報の共有を可能にするパスワードマネージャがたくさんあります。また、悪意のある内部の人間がファイルを盗み見て、アクセスすべきでないところにアクセスしてしまう危険性もあります。

また、外部からの攻撃では、SQLインジェクションのような単純な脆弱性によってデータベースへのバックドアが発見され、パスワードが保存されているディレクトリにもアクセスされた場合、二重の苦しみを味わうことになります。これは、実現するにはあまりにも多くのエラーを伴う手順だと思いますか？悲しいことに、2011年に発生したソニーの情報漏えい事件では、まさにこのシナリオが起こりました。100万件以上の顧客のパスワードが平文で保存されており、Lulzsecのハッキンググループは、一般的なSQLインジェクション攻撃によって、これらのパスワードにアクセスしたのです。

すべてのパスワードは、サポートするフレームワーク内で利用可能なあらゆる防御策によって保護されるべきです。Terraformでは、パスワードをテンプレートファイルに保存してはいけません。インフラストラクチャ・プロバイダーによっては、AWS Secrets ManagerやAzure Key Vaultのような安全なストレージを使用することが推奨されます。

ユーザーに安全なパスワードの作成を強制するのは良いアイデアですが、それに加えてバックエンドでも役割を果たす必要があります。パスワードを平文で保存しないようにすることは、ユーザーとシステムの保護に大いに役立ちます。パスワードを平文で保存することの主な危険性は、アクセス制御が不十分なことです。つまり、誰でも見ることができるのです。特にIaC環境では、突然多くの人が機密情報にアクセスできるようになるため、パスワードを適切にハッシュ化し、どうしてもアクセスが必要な人だけに許可を与えることが必要です。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性について、また、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守る方法について、より詳しい情報をご覧いただけます。また、Secure Code Warrior トレーニングプラットフォーム内のIaC チャレンジのデモを試すことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。