{"id":19701,"date":"2021-10-07T11:47:00","date_gmt":"2021-10-07T09:47:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=19701"},"modified":"2021-09-16T09:55:07","modified_gmt":"2021-09-16T07:55:07","slug":"apis-sicherer-machen-vier-massnahmen-die-jedes-unternehmen-ergreifen-sollte","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=19701","title":{"rendered":"APIs sicherer machen: Vier Ma\u00dfnahmen, die jedes Unternehmen ergreifen sollte"},"content":{"rendered":"\n

Autor\/Redakteur: Daisuke Watanabe, Senior Channel Sales Engineer bei Zix<\/a>\/gg<\/p>\n\n\n\n

Programmierschnittstellen (APIs) sind grunds\u00e4tzlich eine gute Sache: Sie vereinfachen den Programmiervorgang und erschlie\u00dfen den Zugang zu einer F\u00fclle von Daten und Ressourcen, die sonst nicht so einfach nutzbar w\u00e4ren. Davon profitieren auch Anwender, die sich mehr Informationen und Synergien per Knopfdruck w\u00fcnschen, in den Programmen und Abl\u00e4ufen. Bestehende und neue L\u00f6sungen k\u00f6nnen gute APIs zweifelsohne auf vielfache Weise nutzen. Das macht sie jedoch auch zu einem lukrativen Ziel f\u00fcr Bedrohungsakteure. Daher ist es so wichtig, ein Augenmerk auf die Sicherheit von APIs zu haben und die damit verbundenen Risiken zu minimieren. Ganz gleich, ob ein Unternehmen Drittanbieter-APIs nutzt oder selbst entwickelte: Zur Risikominimierung ist es unerl\u00e4sslich, diese APIs zu sch\u00fctzen und eine gute API-Hygiene zu gew\u00e4hrleisten.<\/p>\n\n\n\n

\"\"<\/a>
Bild: Shutterstock<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Die Schwachstellen von APIs<\/strong><\/p>\n\n\n\n

Sicherheitsl\u00fccken in APIs entstehen oftmals durch schlechte Programmierung, das hei\u00dft es erfolgt keine Absicherung gegen m\u00f6gliche Fehlerquellen, und der Sicherheit wird beim Design keine hohe Priorit\u00e4t einger\u00e4umt. Dies gilt insbesondere f\u00fcr offene APIs von Dritten, bei denen m\u00f6glicherweise mehrere Autoren mitwirken, ohne dass ein standardisierter, sicherer Rahmen vorhanden ist. Was erschwerend hinzu kommt: Oft bleibt unklar, wer f\u00fcr die Sicherheit offener APIs zust\u00e4ndig ist \u2013 derjenige, der die offene API entwickelt hat, oder der Entwickler, der sie nutzt und erweitert. Die Frage der Verantwortlichkeit f\u00fcr sichere Programmierpraktiken liegt immer noch in einer Grauzone. Solange die Zust\u00e4ndigkeit ungekl\u00e4rt ist, bleibt das Risiko von Angriffen allerdings sehr hoch.<\/p>\n\n\n\n

Gef\u00e4hrlich wird es auch dann, wenn derjenige, der das API nutzt, nicht wei\u00df, wo der Grenzwert des API-Subsystems liegt: \u00dcber eine aussagekr\u00e4ftige Aktivit\u00e4tsprotokollierung kann nachvollzogen werden, wer Zugriff auf das API hat und diese nutzt. Fehlt ein solches Protokollierungssystem, und ist zudem kein Grenzwert f\u00fcr die H\u00f6chstauslastung vorhanden, ist ein Systemabsturz die m\u00f6gliche Folge. Genau hier setzen viele Denial-of-Service-Angriffe (DoS) an, bei denen Angreifer ein API mit Verbindungen aus verschiedenen Quellen \u00fcberfluten und so das System \u00fcberlasten, ohne dass ein Failover vorgesehen w\u00e4re.<\/p>\n\n\n\n

Vier Ma\u00dfnahmen f\u00fcr eine gute API-Hygiene<\/strong><\/strong><\/p>\n\n\n\n

Bestandsaufnahme und Verwaltung: <\/strong>Mit APIs l\u00e4sst sich viel gewinnen \u2013 aber auch viel verlieren. Die Sicherheit eines API sollte immer im Voraus bedacht und nie zur \u201eAufgabe der anderen\u201c gemacht werden. Die Entwicklung sicherer Praktiken beginnt bei der Bestandsaufnahme und Verwaltung der vorhandenen APIs. Erstaunlicherweise wissen viele Unternehmen gar nicht, welche APIs bei ihnen im Einsatz sind. Mit entsprechenden Scans zur Inventarisierung der APIs l\u00e4sst sich das \u00e4ndern. Diese Informationen m\u00fcssen anschlie\u00dfend zusammen mit den DevOps-Teams verwaltet und auf dem neuesten Stand gehalten werden \u2013 insbesondere bei APIs von Dritten.<\/p>\n\n\n\n

Aktivit\u00e4tsprotokollierung und Monitoring: <\/strong>Unternehmen sollten einen \u00dcberblick dar\u00fcber haben, wie ihre APIs genutzt werden und welches Verhalten und welche Lastmuster normal sind. Nur dann ist es m\u00f6glich, Anomalien oder Aktivit\u00e4tsspitzen auf bestimmte Ereignisse zur\u00fcckzuf\u00fchren oder festzustellen, wann ungew\u00f6hnliche Abweichungen vorliegen, die m\u00f6glicherweise auf eine Bedrohung hinweisen.<\/p>\n\n\n\n

Authentifizierung und Berechtigung: <\/strong>Eine gravierende Schwachstelle bei vielen \u00f6ffentlich zug\u00e4nglichen APIs ist die mangelhafte oder nicht vorhandene Authentifizierungs- und Autorisierungssteuerung. Problematisch wird es auch, wenn private APIs pl\u00f6tzlich \u00f6ffentlich zug\u00e4nglich gemacht werden, ohne dass an die Berechtigungssteuerung gedacht wird: Solche APIs bilden oft das Einfallstor zu den Datenbanken eines Unternehmens. Es ist daher immens wichtig, den Zugang zu dieser Eingangst\u00fcr zu kontrollieren und sie f\u00fcr Unbekannte \u201everschlossen\u201c zu halten.<\/p>\n\n\n\n

Zugriff und \u00dcbertragung: <\/strong>APIs unterst\u00fctzen \u00fcblicherweise Funktionen zum Abrufen und \u00dcbertragen von Daten. In diesem Kontext und angesichts der strengen Vorschriften auf nationaler und globaler Ebene muss klar sein, welche Daten im eigenen System wohin \u00fcbertragen werden. Nur so l\u00e4sst sich entscheiden, ob diese Daten verborgen werden m\u00fcssen. Hier einige Vorschl\u00e4ge: Beseitigen Sie den Zugang zu Informationen, die nicht weitergegeben werden d\u00fcrfen. Verschl\u00fcsseln Sie die Nutzdaten insbesondere dann, wenn es sich um sensible \u201eidentifizierbare\u201c Informationen handelt. Unternehmen sind verantwortlich f\u00fcr die Einhaltung der Datenvorschriften ihrer Anwendung.<\/p>\n\n\n\n

Um moderne Anwendungen schneller programmieren zu k\u00f6nnen, verwenden Unternehmen heute bevorzugt APIs. Doch sie sollten sich der damit verbundenen potenziellen Risiken bewusst sein und eine Vorstellung von \u201esicheren APIs\u201c entwickeln. Ob offene oder geschlossene APIs: Unternehmen m\u00fcssen unabh\u00e4ngig von ihrer Gr\u00f6\u00dfe von Anfang an eine gute Sicherheitshygiene gew\u00e4hrleisten. Das bedeutet nicht, dass Unternehmen ihre APIs von Grund auf neu entwickeln und geschlossen halten m\u00fcssen. Aber sie sollten die Risiken kennen und alle APIs mit der gebotenen Sorgfalt \u00fcberwachen, wenn sie die Sicherheit von Daten und Systemen Dritten anvertrauen<\/p>\n","protected":false},"excerpt":{"rendered":"

Programmierschnittstellen (APIs) sind grunds\u00e4tzlich eine gute Sache: Sie vereinfachen den Programmiervorgang und erschlie\u00dfen den Zugang zu einer F\u00fclle von Daten und Ressourcen, die sonst nicht so einfach nutzbar w\u00e4ren. Davon profitieren auch Anwender, die sich mehr Informationen und Synergien per Knopfdruck w\u00fcnschen, in den Programmen und Abl\u00e4ufen. Bestehende und neue L\u00f6sungen k\u00f6nnen gute APIs zweifelsohne auf vielfache Weise nutzen. Das macht sie jedoch auch zu einem lukrativen Ziel f\u00fcr Bedrohungsakteure. Daher ist es so wichtig, ein Augenmerk auf die Sicherheit von APIs zu haben und die damit verbundenen Risiken zu minimieren. Ganz gleich, ob ein Unternehmen Drittanbieter-APIs nutzt oder selbst entwickelte: Zur Risikominimierung ist es unerl\u00e4sslich, diese APIs zu sch\u00fctzen und eine gute API-Hygiene zu gew\u00e4hrleisten.<\/p>\n","protected":false},"author":1,"featured_media":19703,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[8,37],"tags":[4185,6264,1261,198,15257],"class_list":["post-19701","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artikel","category-security","tag-api","tag-entwicklung","tag-monitoring","tag-programmierung","tag-zix"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/19701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=19701"}],"version-history":[{"count":1,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/19701\/revisions"}],"predecessor-version":[{"id":19704,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/19701\/revisions\/19704"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/media\/19703"}],"wp:attachment":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=19701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=19701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=19701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}