php - Windows miljøvariabel vs Config fil

Indlæg af Hanne Mølgaard Plasc

Problem



Der er en webapp jeg arbejder på. Det er PHP baseret på en Apache webserver.


I produktionsservere trækker applikationen nogle 'følsomme' oplysninger såsom adgangskoden til databasen og databasens brugernavn fra Windows-miljøvariablerne. Dette gøres i stedet for at sætte informationen i en config-fil i applikationen.


Jeg har brugt config filer selv, så jeg tænkte på fordele/ulemper. Jeg ser ikke meget på at gøre det som de gør det, men jeg er sikker på, at jeg ikke tænker på det korrekt.


Her er min tage:


Ulemper



  1. Enhver, der får adgang til Windows-maskinen, kan bare gå ind i Windows-miljøvariablerne og se dem alligevel.

  2. Ændring af oplysningerne kan ikke gøres uden at lukke serveren. Der har været tilfælde, hvor vi har ændret miljøvariablerne og måtte lukke apache fuldstændigt for at kunne genoplaste de nye værdier fuldt ud.



Fordele



  1. Når du flytter fra dev til qa, til prod-maskiner, skal app-konfigurationsfilerne ikke ændres, fordi hver server vil have de nødvendige data allerede indstillet i miljøvariablerne. (Jeg behøver ikke 'huske' at bruge den korrekte konfigurationsfil, fordi miljøvariablerne allerede er indstillet for hver server).

  2. Sikkerheden kan strammes, så kun administratorer kan se miljøvariablerne. Ikke sikker på om Windows kan gøre dette, men jeg er sikker på, at der er noget registerredigering, der kan tillade dette.



Hvad er dit synspunkt?

Bedste reference


Hvad du virkelig taler om, er kontrollen med adgangen til følsomme oplysninger, og den bedste måde at gøre dette på er at bruge \_access\_control\_ mekanismerne indbygget i det underliggende OS. Efter min mening kan du ikke gøre dette effektivt med miljøvariabler på Apache-niveauet, så jeg finder det svært at tænke på nogen overbevisende fordele, som ville få mig til at støtte denne mulighed.


Du kan gøre dette ved hjælp af en fil til at gemme indholdet, f.eks. en config.php fil, som har den relevante adgangskontrol. Begræns omfanget af denne fil til kun at indstille dette begrænsede antal parametre, der skal beskyttes., F.eks.


<?php
$DBuser   = "abd";
$DBpasswd = 'fred:ere12#';


Dette kan kun kompromitteres af en person på serveren, der har læst adgang til filen. (Selvom dette er i en web-tilgængelig mappe, vil adgang til dette af URI ikke afsløre denne information. Kan du se hvorfor?)


Som paulsm4 foreslår at forvirre dette ved kryptering, forhindrer enhver med afslappet læsadgang at se disse data. Men , dette er ikke en sikkerhedsmekanisme, da vi bør antage, at enhver, der har adgang til config.php-filen, også har adgang til scriptet, der læser og afkod disse parametre og kan simpelthen genkonstruere dette procedure.


Faktisk i mine ansøgninger bruger jeg en lidt anden tilgang, som jeg giver som et eksempel. Jeg bruger definerer (apps er OO OO og bruger ikke globals) i en lille index.php bootstrap og beholder alle andre konfigurationsdata i min D/B


<?php
define( 'SQL\_CONTEXT', 'DB:user:pwd:tableprefix' );
define( 'ROOT\_DIR', dirname(\_\_FILE\_\_) );
define( 'START\_TIME', microtime() );
// a couple of other app-specific defines go here

if( ( @include( "./\_cache/dispatcher.class.php" ) ) != 1 ) {
    require("./\_include/functions.php");
}

Dispatcher::dispatch();


Dette er bygget til dev, min test VM og prod af et installations script, der har nogle redigeringer til at indsætte denne følsomme info i APPROOT/index.php, så jeg ikke behøver at holde denne følsomme info i min git repository.

Andre referencer 1


Jeg vælger, hvad der er mere operationelt praktisk for dig (det lyder som miljøvariabler gør dit liv lettere - så gå efter det) ...


... og derefter krypter tekststrengen.

Andre referencer 2


Forudsat Windows NT-arkitektur (8, 7, Vista, XP ...)


Hvis bruger A har en USER-miljøvariabel 'PASSWORD', kan bruger B (som ikke er administrator) ikke læse brugerens USER-miljøvariabel 'PASSWORD', så den er sikker, så længe bruger B ikke er Admin.


Du bør køre dine forskellige programmer som forskellige brugere.


Du bør også beskytte fysisk adgang til dine computere.