Laden...

Umgang mit Secrets in Webhosting-Paketen

Erstellt von Paschulke vor 2 Jahren Letzter Beitrag vor 2 Jahren 449 Views
P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 2 Jahren
Umgang mit Secrets in Webhosting-Paketen

Hallo,

ich versuche eine Web-API in ASP.NET Core zu erstellen. Mache so etwas zum ersten Mal außerhalb meines localhosts. Grundsätzlich komme ich mit den Anleitungen von Microsoft ganz gut voran. Aber beim Thema Sicherheit weiß ich nicht, wie ich das in einer Hosting-Umgebung umsetze, die nicht komplett in meiner Hand ist (also kein VServer o. ä.). Ich nutze ein Webhosting-Paket von Centron (Economy).

Dier verlinkte Microsoft-Artikel gibt mir Informationen, wie ich in der Entwicklung vorgehe, aber nicht wie ich das in der Produktion mache. Und selbst wenn ich versuchen würde den Secret Manager zu verwenden - wie mache ich das auf einem Web-Server. Dort steht mir meines Wissens keine Kommandozeile oder Power Shell oder dergleichen zur Verfügung. Ich müsste ja irgendwie die secret.json ins Benutzerverzeichnis bekommen. Oder übersehe ich da etwas?

Mir fehlt da glaube ich der grundsätzliche Ansatz. Über jede Information oder gute Links (gerne in deutsch 😉) wäre ich dankbar.

P
441 Beiträge seit 2014
vor 2 Jahren

Das kommt ganz auf deine Umgebung an.

In Azure gibt es die Möglichkeit das in einen Key Vault (Geheimnisspeicher) auszulagern. Azure übernimmt dann die Bereitstellung der Authentifizierung ggü. dem Key Vault.
On Prem gibt es andere Anbieter, HashiCorp Vault z.B.

P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 2 Jahren

Ich habe leider keine Azure Umgebung. So wie ich das Preismodell verstehe, ist das glaube ich für mich überdimensioniert. Ich will lediglich eine Api für eine App anbieten, die nur wenige Nutzer nutzen werden (Vereins-App). Vor allem geht es mir auch darum, mich erstmal in das Thema einzufinden.

Das muss doch ein Standard-Problem sein, das jeder haben müsste, der so ein Webhosting-Paket verwendet, wie ich es tue. Oder ist es üblich die Secrets einfach in der Web.config o. ä. zu speichern (wie ich es in vielen Anfängertutorials gesehen habe)?

16.842 Beiträge seit 2008
vor 2 Jahren

. Oder ist es üblich die Secrets einfach in der Web.config o. ä. zu speichern (wie ich es in vielen Anfängertutorials gesehen habe)?

Nein.

Secrets werden niemals innerhalb der Anwendungsumgebung gespeichert.
Manche Anbieter interessiert das aber nicht und bieten Dir halt nichts an. Bei anderen kannst Umgebungsvariablen setzen - und Cloud-Plattformen bieten extra Services dafür.
Musst halt vergleichen.

Wenn Du Dir den Azure Preiskalkulator anschaust, dann siehst, dass ne Webseite mit ca. 8€ im Monat zu hosten ist.
Gibt auch Möglichkeiten komplett kostenlos Sachen zu hosten, weil Du gewisse Frei-Kontingente (zB Functions) hast. Deswegen evaluiert man sowas bevor man eine Zeile Code schreibt 😉

P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 2 Jahren

Wenn Du Dir den Azure Preiskalkulator anschaust, dann siehst, dass ne Webseite mit ca. 8€ im Monat zu hosten ist.

Das hört sich gut an. Dann muss ich nochmal genauer gucken. Danke!

P
Paschulke Themenstarter:in
69 Beiträge seit 2011
vor 2 Jahren

Aber trotzdem verstehe ich nicht, wie andere das mit einem normalen Web-Hosting Paket machen!? Das sind doch Grundlagen, die in jeder Web-Anwendung möglich sein müssen, oder?

16.842 Beiträge seit 2008
vor 2 Jahren

Manche Anbieter interessiert das aber nicht und bieten Dir halt nichts an. Bei anderen kannst Umgebungsvariablen setzen (..)

B
45 Beiträge seit 2009
vor 2 Jahren

Für eine solche Anwendung sollte es ok sein wenn du die secrets in der web.config/appsettings speicherst. Wenn jemand Zugriff auf den Server hat hast du so oder so verloren. Dann kann der Angreifer auch die Umgebungsvariablen und das Client Secret für die Azure Key Vault auslesen.

Für das Deployment ist es einfacher wenn du Umgebungsvariablen setzt dann musst du die web.config/appsettings nicht anpassen.

16.842 Beiträge seit 2008
vor 2 Jahren

..und das Client Secret für die Azure Key Vault auslesen.

.. weswegen auch die System Identities die sicherere Variante ist, die ohne Credentials auskommt. Man kann dann halt auch einfach nichts verlieren.
Verwaltete Identitäten für Azure-Ressourcen
Aber ja: gibts so aktuell halt auch nur in Azure.