È sicuro utilizzare un account AD per eseguire un pool di app in IIS al fine di fornire autorizzazioni di lettura / scrittura SQL a un'app Web?

Question

È sicuro utilizzare un account AD per eseguire un pool di app in IIS al fine di fornire autorizzazioni di lettura / scrittura SQL a un'app Web?

#1 da (1 voti)

0

Ho lavorato a un'applicazione web Intranet che fornisce accesso in lettura / scrittura, basato su ruoli a un database.

Mi è stato chiesto di configurare l'applicazione IIS per utilizzare un account AD per il pool di applicazioni, al fine di fornire le autorizzazioni del database. La ragione di ciò è di evitare l'accesso in lettura / scrittura ai singoli utenti.

Sono preoccupato per la possibilità che il codice dannoso venga aggiunto al server e quindi per accedere al database in virtù del pool di app. È una preoccupazione valida? Ci sono altri rischi o preoccupazioni con questo approccio?

sql-server iis active-directory web-application

posta Beofett 20.03.2018 - 15:11

fonte

1 risposta

Leggi altre domande sui tag sql-server iis active-directory web-application

Bypass WAF / IDS con SQLMAP? [chiuso] Ottenere un errore sospetto in apache error.log (DJANGO)

score 1 · Answer 1

From my point of view your concern is valid. And managing access from your IIS web server to your SQL server database with such configuration is a good approach. It is also true that if your web server is compromised by a malicious code execution (source), attacker could elevate privileges, collect credentials, impersonate any IIS App Pool account and get access to your SQL Server. I can suggest the following and specific security recommendations to increase your architecture security :

Gestione del ciclo di vita per l'account di servizio:

Definisci una rotazione dei criteri password per cambiare frequentemente le password (alcune soluzioni Gestione accesso password possono risolvere questo problema)
Utilizza criteri password complessi
Per ridurre il carico di lavoro dai punti precedenti, utilizzare Account del servizio gestito ( fonte ). Forniranno account con password complesse e rotazione automatica
Rispetta il privilegio minimo (come menzionato da @Jeroen) per ciascuno dei tuoi pool di app e non concedere mai i privilegi di amministratore admin o DB completi a un account di servizio
Utilizza l'autenticazione Kerberos (non attivata per impostazione predefinita). Ciò richiederà parecchie configurazioni ( origine ) e l'uso di SPN

Sicurezza del server:

Abilita la registrazione avanzata di Windows e la registrazione PowerShell per rilevare comportamenti strani (come nuovo processo, arresto anomalo dell'applicazione, accessi non riusciti, nuovo servizio, spostamento laterale ...)
Abilita la registrazione SQL Server
Abilita i registri IIS (file in formato txt)
Non conservare i server front-end nella stessa rete o sottorete dei server sensibili (ad es .: server di database, AD, PKI, ...) e utilizzare un firewall per filtrare solo il traffico necessario (nel tuo caso la porta utilizzata dalla tua istanza SQL).
Cambia il server IIS in modalità Core ( source ) per ridurre la sua esposizione superficiale

So at the end there is no "magic" solution to address your issue, except following basic and advanced security best practices. Having a log collector (eg: SIEM) in place will be also helpful to increase your security coverage from all your logsources (firewall, Windows, Linux, Unix, routers, IDS, IPS, ...).