Ankündigung

Einklappen
Keine Ankündigung bisher.

Wie technische Passwörter für APIs sicher ablegen und verwenden?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Wie technische Passwörter für APIs sicher ablegen und verwenden?

    Ihr werdet es alle kennen, man erstellt ein Tool oder eine App welche Zugriff auf verschiedene andere Dienste benötigt, wie z.B. ein SFTP/SSH, LDAP, REST-API, o.ä.
    Für den Zugriff benötigt die Software eine Zugangskennung irgendwelcher Art. Als Anfänger platziert man das direkt im Code, als fortgeschrittener Programmierer dann in separaten conf-Dateien in einem anderen Verzeichnis.
    So oder so, würden diese Informationen in der Regel im Klartext auf irgendeinem Webserver liegen oder sind gar Bestandteil eines CVS repositories.

    Welche Methoden verwendet ihr um diese, für die software notwendigen Zugangskennungen so sicher wie möglich aufzubewahren und zu verwenden?
    Irgendwann braucht eine Routine natürlich dann username/password/token im Klartext, also wenigstens zur Laufzeit.

  • #2
    Zugangsdaten werden heutzutage oftmals in Umgebungsvariablen gehalten.
    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    Kommentar


    • #3
      Hab ich auch schon überlegt, so wie man das häufig bei Docker-Containern sieht, ja?

      Aber das ist ja ein Henne/Ei Problem. Wo kommt diese Umgebungsvariable her? Sie muss ja in den Start-Kontext der Applikation gebracht werden. Würde ich ein PHP-Skript auf der Linux-Shell ausführen, dann könnte ich das in meine persönliche Benutzerumgebung einsetzen. Dann aber läuft das Ding nur unter meinem User. Das wäre ok, wenn es sich um "private" Kennwörter handeln würde, aber in der Tat sind dort oft auch recht starke Konten hinterlegt die einen umfangreichen Zugriff auf einen Dienst gewähren (admin-ähnlich). Die möchte ich ggf. nicht jedem User des Skripts zugänglich machen.

      Auch war eine Idee ob man in die Skripte nicht eine Methode implementiert, welche sich das zu verwendende Username/Password mittels eines Tokens (ID) zur Laufzeit irgendwo her holt. Dann wüsste man beim lesen des Skriptes nichtmal welches Benutzerkonto verwendet wird. Ein solcher Lieferdienst wäre natürlich hochgefährlich, denn er sollte nicht einfach PWs auf Wunsch ausliefern. Es muss also immer sowas wie eine Zugriffskontrolle im Token stecken, sprich das Token gilt nur für eine Kennung in Kombination mit dem Script und ggf. der IP/Hostname von dem aus es angefragt werden darf.
      Das wäre am Ende natürlich auch nur obfuskiert. Jemand der ein Script ändern kann, kann sich einfach ein print() einbauen

      Kommentar


      • #4
        Aber das ist ja ein Henne/Ei Problem.
        Ist es doch immer, ganz unabhängig vom Medium. Irgendwer muss die Daten irgendwohin packen...

        sind gar Bestandteil eines CVS repositories
        ... wo sie mal überhaupt nix verloren haben

        Jemand der ein Script ändern kann, kann sich einfach ein print() einbauen
        Umgebungsvariablen werden für bestimmte Benutzeraccounts vergeben... idealerweise darf dieser Benutzer dann keine Änderungen an PHP Dateien vornehmen.
        Bekommt ein Hacker Zugriff auf einen Account mit erweiterten Rechten um Änderungen an PHP Dateien vorzunehmen, sind die Umgebungsvariablen mit Passwörtern nicht gesetzt.
        Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

        Kommentar


        • #5
          Zitat von lstegelitz Beitrag anzeigen
          Umgebungsvariablen werden für bestimmte Benutzeraccounts vergeben... idealerweise darf dieser Benutzer dann keine Änderungen an PHP Dateien vornehmen.
          Bekommt ein Hacker Zugriff auf einen Account mit erweiterten Rechten um Änderungen an PHP Dateien vorzunehmen, sind die Umgebungsvariablen mit Passwörtern nicht gesetzt.
          Dann aber müssten die Rechte die das Skript für die Ziel-Dienste benötigt auch userbezogen sein. Wenn ich also z.B. sowas wie einen API-User benötige welcher in einem Dienst Benutzer anlegen/ändern kann, dann reicht hier nicht einer, sondern ich müsste jedem User welcher mit diesem Skript arbeiten soll, dieses Recht auf der Dienst-Seite einräumen...

          Wenn ich so drüber nachdenke wäre das, obgleich es mir anfangs unnötig komplex vorkam, vermutlich sogar die richtige Wahl, denn bei einem Proxy-Konto ist sonst auch nie klar wer diese Aktionen ausgeführt hat. Zudem könnte ich so einzelne User sperren, wenn diese die Gruppe verlassen ohne das allgemeine API-Kennwort ändern zu müssen, was derjenige ggf. mit seinen Möglichkeiten hätte herausfinden können. Hmm...

          Kommentar


          • #6
            Ich meinte eigentlich den System User unter dem der Webserver läuft, nicht einen API account oder sowas.

            Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

            Kommentar


            • #7
              Das wäre ja gleichbedeutend. Also wenn ich etwas mit "meinem" User laufen lasse, ein Skript z.B., oder wenn ich das dem "www-data" (oder wie auch immer der User vom Webserver heißt) etwas "unterschiebe". In beiden Fällen müsste ich wissen welche Umgebungsvariablen es braucht und wie ich diese in die Umgebung bekomme.

              Beim Webserver wäre dann aber wohl ein phpinfo() sehr verräterisch...

              Kommentar


              • #8
                Suchst du so etwas wie https://learn.hashicorp.com/vault ?
                Damit kannst du Secrets zentral verwalten und den Zugriff wer drauf zugreifen darf steuern.

                Kommentar

                Lädt...
                X