2017-07-27 4 views
0

Angenommen, ich habe meinen PowerShell-Code, der bestimmte Aktionen für mein Azure-Abonnement erfordert. Ich habe verstanden, dass sich Azure mit meinem Azure-Benutzernamen oder einem Azure-Dienstprinzipal anmelden muss.So schützen Sie den Azure-Dienstprinzipal in Ihrem PowerShell-Code

In meinem Fall würde ich gerne einen Service Principal verwenden, da viele Leute diesen Code benutzen werden und ich möchte nicht jedem Zugang zu meinem Abonnement geben. Also biete ich nur Zugang zu diesem SP an.

Ich habe festgestellt, dass ich die App ID und den Schlüssel in meinen Code einfügen muss, wenn mein Code kompromittiert ist. Dann könnte jemand von außerhalb unseres Unternehmens die App ID und den Schlüssel verwenden, um sich einzuloggen rein und mach Sachen auf meinem Abo.

Gibt es eine Möglichkeit, mich vor solchen Sicherheitsrisiken zu schützen? Ich sehe, dass es auch einen Abschnitt über Azure AD gibt, mit dem ich Benutzer/Gruppen angeben kann, die auf den Service Principal (Azure App) zugreifen können. Aber wird es mehr wie eine doppelte Authentifizierung sein? Kannst du mir bitte in die richtige Richtung zeigen?

Wenn Sie auch mit mir einige Beispielcode teilen könnten, wird es sehr geschätzt.

+3

Richten Sie den Dienstprinzipal ein, um sich über ein Zertifikat anzumelden, und verteilen Sie das Zertifikat mit dem Skript und lassen Sie es so authentifizieren. Wenn dann jemand von außen Ihr Skript in die Hände bekommt, kann es nicht Ihr Abonnement beeinflussen, ohne das Zertifikat zu besitzen. – TheMadTechnician

+0

Die Verwendung des Zertifikats beseitigt auch nicht das Risiko – iSi

+0

@TheMadTechnician Ich stimme demMadtechnician zu. Sie erstellen einen Service-Principal mit Zertifikat und geben das Zertifikat an die vertrauenswürdigen Personen weiter. Verwenden Sie Service-Prinzipal + Zertifikat, um sich bei Ihrem Abonnement anzumelden. '$ Certs = Get-ChildItem cert: \ CurrentUser \ Meine \ | Where-Object {$ _. Betreff-match $ CertificateName; Add-AzureRmAccount -ServicePrincipal -CertificateThumbprint $ Cert.Thumbprint -ApplicationId $ ServicePrincipalApplicationId -TenantId $ TenantId' –

Antwort

0

Ehrlich, bitte tun Sie es nicht so. Jeder, der Zugriff auf das Zertifikat erhält (wenn Sie es mit Ihrem Code verteilen), hat auch Zugriff als Dienstprinzipal für Azure.

Ich würde vorschlagen, dass Sie ein Azure Automation Runbook erstellen und eine webhook daran anfügen. Sie könnten dann eine kleine HTML-Datei erstellen, die das Runbook ausführen würde (Sie werden aufgefordert, die gewünschten Parameter einzugeben). Auf diese Weise können die Benutzer nur den Code ausführen, den Sie eingerichtet haben (über den Webhook), und Sie können die Webhook-URL (durch Löschen und Neuerstellen) periodisch wechseln.

+0

Das Problem ist, dass die Aktion, die der Code ausführt, zu gefährlich ist und das heißt, wenn jemand Zugriff auf die Webseite hat, hat er die Möglichkeit sie auszuführen und das sollte vermieden werden. Ich habe auf eine zusätzliche Authentifizierungsschicht gehofft, bevor sie den Code über den SP ausführen ... – iSi

+1

https://docs.microsoft.com/en-us/azure/automation/automation-webhooks#security TLDR: Sie können ein Pre hinzufügen -shardkey oder andere Validierungsformular im Nachrichtentext und Schreiblogik, um das zu behandeln. – CtrlDot

+0

Danke für den Link. Ich denke, alles hat seine eigenen Risiken ... will es nur so weit wie möglich reduzieren ... was ist die Zugriffsliste in der Azure AD Application (SP)? Könnte mit diesem Szenario zusammenhängen? – iSi

Verwandte Themen