Schützen von Geheimnissen mithilfe von Plattformfunktionen

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

Auflisten der Optionen und empfohlenen Vorgehensweisen für die Speicherung von Geheimnissen in verwalteten Paketen
Erstellen von Anmeldeinformationen mit Namen, um Callout-Endpunkte und die zugehörigen Authentifizierungsparameter sicher zu definieren
Beschreiben, wie geschützte benutzerdefinierte Einstellungen und API-Felder für geschützte benutzerdefinierte Metadaten zum Speichern von Geheimnissen genutzt werden können

Speichern von Anwendungsgeheimnissen in Salesforce

In der ersten Einheit wurde behandelt, wie Geheimnisse erkannt werden und wer Zugang zu ihnen haben sollte. Als Nächstes sehen wir uns an, wie sie geschützt werden.

Das ist einfach, da die Salesforce-Plattform über eine Reihe von Funktionen zum Speichern und Schützen von Geheimnissen verfügt. Es handelt sich dabei um die Folgenden:

Anmeldeinformationen mit Namen
Benutzerdefinierte Einstellungen (geschützt, nicht geschützt, nicht verwaltet und verwaltet)
Benutzerdefinierte Metadatentypen

In dieser Einheit erläutern wir jede dieser Optionen zur Speicherung von Geheimnissen, damit Sie sicherstellen können, dass der Zugriff auf sensible Informationen entsprechend eingeschränkt ist.

Anmeldeinformationen mit Namen

Anmeldeinformationen mit Namen geben den URL eines Callout-Endpunkts und die zugehörigen erforderlichen Authentifizierungsparameter in einer einzelnen Definition an. Salesforce verwaltet die gesamte Authentifizierung für Apex-Callouts, die Anmeldeinformationen mit Namen als Endpunkt angeben. Sie müssen also Ihrem Apex-Code keine weitere Authentifizierungslogik hinzufügen. Anmeldeinformationen mit Namen können definiert werden, um eine sichere und praktische Methode zum Einrichten dieser Art von Callouts zu bieten. Nach Erstellung können Sie URL-Verweise in Ihrem Code durch Verweise auf die Anmeldeinformationen mit Namen ersetzen, was den Code sauberer, einfacher und sicherer macht.

Anmeldeinformationen mit Namen sind besonders nützlich, wenn es darum geht, Callout-Endpunkte zu definieren, auf die in Ihrem verwalteten Paket verwiesen wird. Ohne Anmeldeinformationen mit Namen muss der Entwickler die folgenden Zusatzaufgaben durchführen, um einen authentifizierten Callout einzurichten.

Verweisen auf den URL als Callout-Endpunkt
Registrieren des URL in Ihren Einstellungen für Remote-Standort
Hinzufügen von benutzerdefiniertem Code, um zugehörige Authentifizierungsaufgaben durchzuführen

Nehmen wir zum Beispiel an, Sie haben eine Anwendung, die sich regelmäßig mit einem externen Service verbindet, um Daten abzurufen. Dieser externe Service erfordert jedoch, dass jede einzelne Anforderung einen API-Schlüssel zur Authentifizierung enthält. Häufig erfüllen Entwickler diese Bedingung dadurch, dass sie diesen Schlüssel im Quellcode hartcodieren, damit er in jeder Anforderung verwendet werden kann. Sehen Sie sich das folgende Codebeispiel an:

String key = ‘supersecurepassword’;
HttpRequest req = new HttpRequest();
req.setEndpoint('https://www.example.com/test?APIKEY='+key);
req.setMethod('GET');
Http http = new Http();
HTTPResponse res = http.send(req);
return res.getBody();

Das Hardcodieren ist zwar eine naheliegende Lösung, es gibt bei diesem Ansatz jedoch drei Hauptprobleme.

Jeder, der den Quellcode einsehen kann, sieht auch die eingebetteten Geheimnisse.
Wenn ein Geheimnis aktualisiert wird, müssen alle Vorkommen des Geheimnisses im gesamten Quellcode geändert werden.
Das Portieren dieses Geheimnisses zwischen Anwendungen kann zu vielen weiteren Komplikationen führen.

Hier können Anmeldeinformationen mit Namen die Rettung sein! Anstatt den Wert hart in Ihren Code zu codieren, können Sie Anmeldeinformationen mit Namen nutzen, um Geheimnisse zu speichern. Dies ermöglicht Ihnen, für den Zugriff auf den Geheimniswert auf die Anmeldeinformation mit Namen zu verweisen, als ob es sich um eine andere Variable in Ihrem Code handelt.

Wenn Sie anstelle des eigentlichen Werts Anmeldeinformationen mit Namen verwenden, können nur Benutzer mit dem Profil "Systemadministrator" und Benutzer mit den Berechtigungen "Alle Daten anzeigen" und "Alle Daten modifizieren" auf den Wert zugreifen.

Vorteile von Anmeldeinformationen mit Namen

Anmeldeinformationen mit Namen stellen nicht nur eine Möglichkeit dar, den Zugriff auf Ihre Anwendungsgeheimnisse einzuschränken, sondern machen zudem die Wartung dieser Geheimnisse zum Kinderspiel. Wenn Sie Anmeldeinformationen mit Namen konfiguriert haben, können Sie diese bei Bedarf leicht ändern, indem Sie sie in Ihren Einstellungen ändern. Auf diese Weise enthalten alle Vorkommen in Ihrem Code, die auf das Geheimnis verweisen, niemals veraltete Werte, da sie direkt auf die Anmeldeinformationen mit Namen verweisen.

Wo bieten sich Anmeldeinformationen mit Namen an?

Auch wenn es ziemlich einfach ist, Anmeldeinformationen mit Namen einzurichten, sind sie nicht unbedingt für jeden Anwendungsfall geeignet. Anmeldeinformationen mit Namen eignen sich am besten für einfache Authentifizierungsschemas wie Benutzername und Kennwort oder OAuth 2.0.

Sie haben den Zweck, Administratoren und Entwicklern in Ihrer Organisation die Arbeit einfacher und sicherer zu machen. Allerdings sind sie nicht immer die beste Wahl. Da Benutzer mit der Berechtigung "Alle Daten modifizieren" oder "Apex erstellen" die Anmeldeinformationen mit Namen ändern oder einen Callout dafür vornehmen dürfen, können sie auch auf die durch die Anmeldeinformationen mit Namen geschützten Daten zugreifen. Oder sie können vielleicht sogar die Anmeldeinformationen selbst auslesen. Falls Sie Schutz vor diesen Anwendungsfällen benötigen, z. B. als unabhängiger Softwarehersteller, der ein Paket erstellt, das privat mit Ihren eigenen Cloud-Services kommunizieren muss, sollten Sie andere Optionen wie "Verwaltete geschützte benutzerdefinierte Einstellungen" oder "Verwaltete geschützte benutzerdefinierte Metadatentypen" in Betracht ziehen. Mehr dazu erfahren Sie im nächsten Abschnitt.

Sichere verteilte Geheimnisse

Anmeldeinformationen mit Namen sind ideal für Situationen, in denen Callouts an externe Services in einer Organisation erfolgen, in der Administratoren zum Zugriff auf die zugehörigen Authentifizierungsgeheimnisse berechtigt sind. Aber was tun Sie, wenn Sie verhindern müssen, dass Administratoren die Daten einsehen, oder wenn Sie Geheimnisse auf mehrere Salesforce-Organisationen verteilen möchten?

In diesen Fällen sollten Sie Code in Form eines verwalteten Pakets verteilen. Sie können ganz einfach eine kostenlose Developer Edition-Organisation als Paketerstellungsorganisation für Ihren Code einrichten. Wenn Sie AppExchange-Partner sind, können Sie Developer Edition-Organisationen über Ihr Umfeldzentrum erstellen. Sie können auch die Seite zum Registrieren für eine Developer Edition aufrufen. Innerhalb Ihrer Paketerstellungsorganisation können Sie Apex-Klassen, Apex-Auslöser, Salesforce-Objekte und andere gängige Formen von Metadaten in einem verwalteten Paket bündeln, das problemlos an jede andere Salesforce-Instanz oder -Organisation verteilt werden kann. Sie können sich ein verwaltetes Paket als eine komplexere Version einer ZIP-Datei vorstellen.

Unter Sicherheitsaspekten bietet die Verwendung verwalteter Pakete (im Gegensatz zu nicht verwalteten Paketen oder losem Code) viele bedeutende Vorteile.

Verwaltete Pakete verfügen über die erforderlichen Mechanismen, um automatische Updates, Patches und Fehlerbehebungen per Push-Verfahren zu verteilen, wenn Sicherheitslücken erkannt werden.
Ihr Quellcode ist verborgen (außer bei explizit offen gelegten globalen Apex-Klassen). Das heißt, dass grundlegende Geschäfts- oder Programmlogik nicht so verändert werden kann, dass sie unbeabsichtigt nicht mehr funktioniert oder auf bösartige Weise modifiziert und neu verteilt wird. Verborgener Code verhindert auch, dass im Paket enthaltene Geheimnisse sichtbar sind.
Da Sie für Ihr verwaltetes Paket einen eindeutigen Namespace definieren müssen, werden Probleme durch Namespace-Konflikte verhindert. Außerdem wird Ihr Paket vom lokalen Namespace getrennt, wodurch die in Ihrem Paket enthaltenen Geheimnisse weiter geschützt sind. Standardmäßig kann mit Code, der außerhalb eines verwalteten Pakets ausgeführt wird, nicht auf Paketgeheimnisse zugegriffen werden.

Verwalteten geschützter benutzerdefinierter Einstellungen und benutzerdefinierter Metadatentypen

Während das einfache Packen Ihres Codes in einem verwalteten Paket viele Sicherheitsvorteile bietet, stehen Ihnen bei Verwendung eines verwalteten Pakets auch zwei weitere Funktionen für die Speicherung und Verteilung von Informationen zur Verfügung: geschützte benutzerdefinierte Einstellungen und geschützte benutzerdefinierte Metadaten.

Benutzerdefinierte Einstellungen können für die Speicherung nahezu aller Arten von Daten erstellt werden und sind äußerst flexibel in Bezug auf ihre Einsatzmöglichkeiten und Inhalte. Zusammenfassend lässt sich sagen, dass Sie mit benutzerdefinierten Einstellungen benutzerdefinierte Datensets erstellen können, die dem Anwendungs-Cache offengelegt werden, sodass Sie wiederholte Datenbankabfragen vermeiden und die Effizienz Ihrer Anwendung steigern können. Eine benutzerdefinierte Einstellung kann z. B. dazu dienen, eine Reihe von Daten festzulegen, mit denen die Benutzererfahrung mit einer Anwendung personalisiert wird. Sie könnten auch eine benutzerdefinierte Einstellung erstellen, um eine Liste von Produktnamen zu speichern, auf die auf zahlreichen Seiten verwiesen wird, um schnellen und einfachen Zugriff zu ermöglichen. Im Hinblick auf Anwendungssicherheit können benutzerdefinierte Einstellungen zum Einsatz kommen, um sensible Informationen oder Geheimnisse zu speichern.

Für benutzerdefinierte Einstellungen können unterschiedliche Sichtbarkeitsstufen festgelegt werden. Eine in einem verwalteten Paket enthaltene geschützte benutzerdefinierte Einstellung ist für abonnierende Organisationen weder über Apex noch über die API sichtbar, wodurch es sich gut eignet, bestimmte Arten von Geheimnissen zu speichern. Benutzerdefinierte Einstellungen, die auf öffentliche Sichtbarkeit festgelegt oder in einem nicht verwalteten Paket enthalten sind, lassen sich über Enterprise Web Service Description Language (WSDL) einsehen. Daher ist es wichtig, dass geschützte benutzerdefinierte Einstellungen in einem verwalteten Paket gekapselt werden, wenn sensible Informationen darin abgelegt werden.

Benutzerdefinierte Metadatenfelder können ähnlich wie benutzerdefinierte Einstellungen für die Speicherung von Geheimnissen verwendet werden. Für einen angemessenen Schutz legen Sie die Sichtbarkeit der Felder auf "Geschützt" fest und legen sie in einem verwalteten Paket ab. Geschützte benutzerdefinierte Felder der Metadaten-API eignen sich beispielsweise hervorragend für die Speicherung von API-Schlüsseln oder anderen geheimen Schlüsseln.

Hinsichtlich Sichtbarkeitseinstellungen gibt es sowohl bei benutzerdefinierten Einstellungen als auch bei Metadatenfeldern mehrere Optionen.

Öffentlich (lokal)
Geschützt (lokal)
Öffentlich (verwaltet)
Geschützt (verwaltet)

Die ersten drei Optionen eignen sich für die Speicherung von Daten im Allgemeinen, doch bei Wahl dieser Einstellung kann jeder in der Organisation die Datenwerte einsehen. Wählen Sie diese Optionen nur, wenn Sie öffentlich zugängliche Daten speichern. Für sensible Daten, wie z. B. Anwendungsgeheimnisse, wählen Sie die Konfigurationsoption "Geschützt (Verwaltet)".

Durch die Möglichkeit, die Sichtbarkeit zu deaktivieren, den einfachen Zugriff und die Zwischenspeicherfunktionalität sind benutzerdefinierte Einstellungen und Metadatenfelder geeignete und attraktive Methoden für die Speicherung von Geheimnissen.

Erstellen verwalteter, geschützter benutzerdefinierter Einstellungen

Sie können eine verwaltete, geschützte benutzerdefinierte Einstellung namens "District Secrets" erstellen, um darin Geheimnisse sicher zu speichern. Zum Erstellen einer geschützten benutzerdefinierten Einstellung navigieren Sie zu "Setup", wechseln zu Schnellsuche > Benutzerdefinierte Einstellungen und klicken auf Neu. Definieren Sie Bezeichnung, Objektname, Einstellungstyp und Sichtbarkeit (legen Sie dafür Geschützt fest). Nachdem Sie auf Speichern geklickt haben, können Sie benutzerdefinierte Felder zum Speichern der Geheimnisse hinzufügen.

Screenshot der benutzerdefinierten Einstellungen. Geöffneter Laptop mit der Seite 'Definition benutzerdefinierter Einstellungen' mit Feldern für Bezeichnung, Objektname, Einstellungstyp, Sichtbarkeit und Beschreibung.

Endlich können Sie Ihre Geheimnisse in Ihre geschützten benutzerdefinierten Felder eingeben. Da nur Einstellungsdefinitionen in das Paket einbezogen werden, benötigen Sie Apex oder ein API-Skript, um die Geheimnisse einzutragen, wenn das Paket in der Ziel- oder Abonnentenorganisation installiert wurde.

Verwenden verwalteter geschützter benutzerdefinierter Einstellungen

Sie können auf benutzerdefinierte Einstellungen auf dieselbe Weise wie auf benutzerdefinierte Objekte verweisen. Für den Zugriff auf benutzerdefinierte Einstellungen können Sie Formelfelder, Apex-Methoden für benutzerdefinierte Einstellungen, SOAP-API, Validierungsregeln, Flow usw. verwenden. Verweise auf die geschützte benutzerdefinierte Einstellung können innerhalb desselben verwalteten Pakets, d. h. im gleichen Namespace, vorgenommen werden. Es folgen gängige Apex-Methoden zum Verweisen auf benutzerdefinierte Einstellungen:

getAll()
getValues()
getOrgDetails()
getInstance(Profile_ID)

Im folgenden Beispiel wird getAll() für den Zugriff auf Geheimnisse verwendet, die als benutzerdefinierte Einstellungskomponente gespeichert sind.

Map<String, CustomSettingName__c> mcs = CustomSettingName__c.getAll();

Benutzerdefinierte Metadatentypen

Geschützte benutzerdefinierte Metadatentypen können ebenfalls zum Speichern von Geheimnissen definiert werden, ähnlich wie die zuvor definierten benutzerdefinierten Einstellungen. Wie bereits erklärt, sollten benutzerdefinierte Metadatentypen für die Einbindung in ein verwaltetes Paket definiert werden, damit sie wirksam verborgen und geschützt sind. Der Hauptunterschied besteht darin, dass die in benutzerdefinierten Metadatentypen enthaltenen Daten Metadaten in Ihrer Anwendung darstellen.

Dies kann oftmals vorteilhaft sein. Stellen Sie sich vor, Sie sind ein Entwickler, der in Ihrer Developer Edition-Paketerstellungsorganisation eine neue Anwendung erstellt. Diese Anwendung verfügt über alle Arten cooler Funktionen, einschließlich einer externen API-Integration mit example.com. Für Callouts an example.com müssen Sie irgendwo einen API-Schlüssel speichern. Eine Möglichkeit besteht darin, den geheimen API-Schlüssel in einem benutzerdefinierten Feld zu speichern. Das funktioniert zwar in Ihrer eigenen Developer Edition-Organisation, hat aber auch Nachteile. Also, was ist an diesem Ansatz falsch?

Abgesehen davon, dass es sich um eine unsichere Lösung handelt, gibt es ein Problem mit dem Speichern des geheimen API-Schlüssels in einem benutzerdefinierten Feld, sobald es zu einer erneuten Bereitstellung kommt. Wenn Sie versuchen, all Ihren Code und Ihre Anpassungen in Ihre Produktionsorganisation zu verschieben, wird der Wert Ihres geheimen Schlüssels nicht mit den anderen Daten übertragen. Ihre Daten werden nicht mit Ihrem Änderungsset in die Produktion verschoben. Sie müssen den Schlüsselwert manuell in das Feld einfügen oder ein Skript schreiben, um das Feld ausfüllen zu lassen. Bei einem benutzerdefinierten Metadatentyp hingegen wird der geheime API-Schlüssel wie jede andere Anpassung behandelt und in die Produktion überführt. In diesem Szenario müssen Sie ihn nicht selbst wieder einfügen.

Wie bereits erwähnt, müssen Sie, um Daten in eine benutzerdefinierten Einstellung zu laden, eine Art Skript zur Ausführung nach der Installation schreiben. Bei geschützten benutzerdefinierten Metadatentypen müssen Sie jedoch keine Skripts schreiben. Die in einem benutzerdefinierten Metadatentyp enthaltenen Daten stehen Ihnen als separate Metadaten zur Verfügung, die Sie dem Paket hinzufügen können. Das hört sich doch gut an, oder?

Eine der besten Eigenschaften benutzerdefinierter Metadatentypen ist, dass Sie sie wie beliebige andere benutzerdefinierte Objekte mit SOQL abfragen können. Der einzige Unterschied besteht darin, dass Metadatentypen das Suffix "__mdt" anstelle von "__c" haben. Wenn Sie einen benutzerdefinierten Metadatentyp auswählen müssen, schreiben Sie eine Abfrage wie diese:

SELECT Teacher__c, Coach__c, Counselor__c , Administrator__c FROM District_Profiles__mdt

Diese Codezeile ruft alle Werte von District_Profiles__mdt ab. Das ist ziemlich einfach!

Benutzerdefinierte Einstellungen und benutzerdefinierte Metadatentypen im Vergleich

Sie können zwar entweder benutzerdefinierte Einstellungen oder benutzerdefinierte Metadatentypen zum Schutz von Geheimnissen einsetzen, doch es gibt einige erwähnenswerte Unterschiede zwischen den beiden. Schauen wir uns an, wann welche genutzt werden sollten.

Verwenden Sie in folgenden Fällen geschützte benutzerdefinierte Einstellungen:

Das Geheimnis muss häufig aktualisiert werden und sofort verfügbar sein. Da Metadatentypen in eine Warteschlange gestellt und bereitgestellt werden müssen, sind aktualisierte Geheimnisse in Metadatentypen nicht sofort verfügbar. Daher ist eine benutzerdefinierte Einstellung hier die bessere Wahl.
Sie möchten festlegen, welche Profile und Benutzer auf welche Geheimnisse zugreifen dürfen. Metadatentypen bieten nicht dieselbe Granularität wie hierarchische Typen benutzerdefinierter Einstellungen, bei denen Sie festlegen können, für welche Profile oder Benutzer die Geheimnisse zur Verfügung stehen sollen. Es ist also besser, in diesem Fall eine benutzerdefinierte Einstellung zu wählen.

Verwenden Sie in folgenden Fällen benutzerdefinierte Metadatentypen:

Sie möchten ohne zusätzliche Konfigurationsschritte ein allgemeines Geheimnis verteilen.
Benutzerdefinierte Metadatengeheimnisse können einfach migriert werden, z. B. aus einer Sandbox- oder Entwicklungsumgebung in eine Produktionsumgebung. Bei benutzerdefinierten Einstellungen hingegen müssen Administratoren entweder Skripts für die Ausführung nach der Installation schreiben oder Seiten erstellen und in der neuen Umgebung Geheimnisse manuell eingeben und speichern.