Newsgroup: it.lavoro.informatica
Titolo: amministratori di sistema troppo conservativi?

I nostri amministratori di sistema (che sono un'azienda esterna), gestiscono i server AWS in termini di configurazione, pacchetti installati, patch di sicurezza, etc. 
 
Bene, ora vorremmo installare un agent che fa monitoring e centralizza i log applicativi e di sistema (Datadog). Purtroppo l'agent - sia per l'installazione che esecuzione - richiede diritti di root.
 
Ora gli amministratori si rifiutano di installarlo in quanto non c'e' un pacchetto ufficiale di Canonical, e quindi per ragione di sicurezza, stabilita' e certificazione non possono o vogliono installarlo.
 
Secondo voi e' il caso di fare un putiferio? Trovate la cosa sensata?


Andiamo indietro molti anni e la mia memoria non e' piu' quella di un 
tempo, pero' mi sembra di ricordare che la centralizzazione dei log, 
almeno per quanto riguarda gli accessi, fosse proprio una pratica 
obbligatoria per una delle leggi della privacy. Magari i tuoi 
amministratori lo fanno gia', se non lo fanno mi sa che il putiferio sia 
d'obbligo.


E' molto semplice. Si apre un case a Datadog per chiedergli come certificare l'agent, esisterá pure una maniera "legittima" di installarlo, Canonical o meno.
No, non é una cosa sensata. Come scrive anche Dr.UgoGagliardelli la centralizzazione é un must PER LEGGE. Se sono cosí bravi indichino il piano di rientro, sempre che siano amministratori di sistema contanto di lettera d'incarico. Questi niubbi me li mangiavo a colazione, tempo fa....


Grazie. Intendi accessi via ssh? E sarebbe una legge europea o cosa?
 


non sono a conoscenza di questa legge, cmq l'idea era di aggregare i log applicativi e monitoring di JVM piu' che altro (e magari anche quelli di sistema, ma non era l'idea originale).
 
In effetti non mi pare ci siano pacchetti alternativi, su Canonical. Ad esempio Dynatrace o New Relic.

> In effetti non mi pare ci siano pacchetti alternativi, su Canonical.
 
? ELK è il più famoso in assoluto, LogStash nella fattispecie.
 
Detto ciò NON mi risulta sia un must ne sia scritto da alcuna parte
che i log vadano centralizzati, sarebbe interessante avere gli estremi
di questa legge perché così descritta puzza molto di invenzione, non
me ne vogliano gli altri posters.
 
Quanto al non voler un pacchetto il punto dipende da chi l'ha fatto.
Se io non ritengo affidabile un pacchetto che mi dai non me ne prendo
responsabilità alcuna. Se qualcuno se la prende faccio "da meccanico"
ma altrimenti su una macchina di cui son responsabile io qualcosa di
binario, distribuito da non so chi, aggiornato/auditato ecc da non so
chi non ci arriva manco con richiesta timbrofirmata del mammasantissima
di turno.
 
-- 
usenet⇒nntp per trovarmi

 In effetti non mi pare ci siano pacchetti alternativi, su Canonical. Ad esempio Dynatrace o New Relic.
Sí, peró secondo me il pacchetto te lo puoi scaricare dal loro sito con tanto di chescum md5, e poi deployarlo in locale.
 

 me ne vogliano gli altri posters.
In effetti é scritto malissimo: parlavamo dei soli log di accesso al sistema. Sugli applicativi, no non vi é alcun requisito. La centralizzazione é solo una commodity ...


 sistema, ma non era l'idea originale).
 
Perdonami ma come fate ad operare ignorando il GDPR soprattutto fornendo servizi?
 
Onestamente risulta difficile avere una conversazione sensata non avendo un contesto di riferimento comune.
 
Ciao
  Francesco

 Perdonami ma come fate ad operare ignorando il GDPR soprattutto fornendo servizi?
 
non ignoriamo "il GDPR". Nella fattispecie quale parte stiamo ignorando secondo te?

    Francesco
 
Ciao
Massimo

 In effetti é scritto malissimo: parlavamo dei soli log di accesso al sistema. Sugli applicativi, no non vi é alcun requisito. La centralizzazione é solo una commodity ...
 
Provvedimento adottato dall’Autorità garante per la protezione dei dati 
personali il 27 novembre 2008, recante le “Misure e accorgimenti 
prescritti ai titolari dei trattamenti effettuati con strumenti 
elettronici relativamente alle attribuzioni delle funzioni di 
amministratore di sistema”
 
4.5 Registrazione degli accessi
Devono essere adottati sistemi idonei alla registrazione degli accessi 
logici (autenticazione informatica) ai sistemi di elaborazione e agli 
archivi elettronici da parte degli amministratori di sistema. Le 
registrazioni (access log) devono avere caratteristiche di completezza, 
inalterabilità e possibilità di verifica della loro integrità adeguate 
al raggiungimento dello scopo di verifica per cui sono richieste.
 
Le registrazioni devono comprendere i riferimenti temporali e la 
descrizione dell´evento che le ha generate e devono essere conservate 
per un congruo periodo, non inferiore a sei mesi.
 
Ciao
 
M.

 Secondo voi e' il caso di fare un putiferio? Trovate la cosa sensata?
 
Dipende sempre da cosa avete scritto nel contratto, a fiuto una 
soluzione potrebbe essere chiedergli formalmente qualcosa che svolga 
quel lavoro, dettagliando al massimo le funzioni, senza specificare il 
software e lasciare a loro l'individuazione del prodotto.
Comunque non escludo che il contratto possa essere scritto per dare 
ragione a loro, ne ho visti diversi scritti con l'intenzione di 
scaricare tutte le responsabilità sul fotnitore dare allo stesso la 
possibilità di rifiutare una richiesta in tal senso adducendo le stesse 
motivazioni che hanno detto a te ed avendo ragione.
 
M.

 Massimo
 
Ciao Massimo,
   infatti si parte addirittura da lì: pazienza ci penseranno ispezioni, multe e cause a farlo imparare.
 
Ciao
  Francesco


Quella e' una legge italiana, non europea.

 I nostri amministratori di sistema (che sono un'azienda esterna), 
 
Se questa e` la politica della vostra azienda, dovete stare al gioco. A me non piacerebbe mai avere qualcuno di esterno a gestire le istanze AWS aziendali. Noi abbiamo ELK stacks per tutti gli ambienti e stiamo decidendo se usare NewRelic o qualcosa di piu` semplice (Prometheus/Grafana) per alcuni sistemi. Niente esterni con cui fare i conti.


Intendo accessi autenticati di qualsiasi tipo. E' una legge italiana, 
forse da direttiva europea, non ricordo.

 d'obbligo.
 
Ne dubito fortemente. Significherebbe entrare nel merito dei sistemi che sviluppi. Dipende strettamente dalle tue applicazioni e da come produci i log (con docker, per esempio, e` prassi usare stdout/stderr). Memorizzare gli accessi utente, poi, credo sia obbligatorio (almeno qui in UK) solo in ambienti altamente regolati (per esempio dal Financial Conduct Authority).
Potresti voler usare un ELK stack o altro. 
Piu` che sollevare un putiferio con i loro "amministratori di sistema", io lo solleverei con chi, internamente alla sua azienda, ha deciso che 
1) ci dovessero essere degli "amministratori di sistema" (davvero? Nel 2020? Con DevOps)
2) che tali "amministratori di sistema" dovessero essere esterni. 
Una bella ricetta per spararsi nei piedi, a mio parere.
 

 sistema".
 
Mh, non per fare il maestrino ma nella LUNGA pagina suggerita non si
riporta obbligo di centralizzare i log ma solo di garantire alcune
caratteristiche nella loro gestione, periodo di conservazione, non
modificabilità ecc.
 
Ovvero scusa la rudezza ma come scritto prima non c'è alcuna imposizione
di centralizzazione dei log. Se c'è quotala direttamente, altrimenti
stai affermado che esiste qualcosa senza fornirne prova.



Quindi? Centralizzare, decentrare, duplicare etc. sara' ben una scelta 
del titolare dei dati. o no? A mio parere l'amministratore deve seguire 
le direttive aziendali.


La nostra e' una situazione particolare, per budget e dimensione del team. 
 
Per quanto riguarda DevOps la situazione secondo me non e' cosi' drammatica nel senso che gli sviluppatori non spediscono il pacchetto ai sistemisti, e i sistemisti non fanno il deploy. La scelta e configurazione del AS, sistema di deploy e deploy stesso e' affidato completamente agli sviluppatori.
 
Questi amministratori di sistema, si occupano di cose come mettere in sicurezza il sistema, configurare ssh, il proxy, e i vari servizi AWS con Terraform. Si occupano anche di intervenire urgentemente, magari alle due di notte, nel caso i server non rispondano correttamente.
 
Ecco, nella configurazione dei servizi AWS con Terraform, effettivamente si verifica il problema che hai sottolineato. Cioe' noi sviluppiamo le configurazione in un account diverso e poi gli chiediamo di replicarle nell'ambiente di staging e poi production.
A me questa situazione non piace per niente, in quanto preferirei basare lo sviluppo e soprattutto test sulla medesima configurazione Terraform (cercheremo di farlo cmq, anche se non so quanto sia effettivcamente portabile la cosa).
Se fossero parte del team, sicuramente questo problema non ci sarebbe.


Peer la precisione John, era proprio questo l'articolo esatto: peró questa é conservazione, non tanto centralizzazione. Per il resto é ok, si parlava giusto di quello.


No no, non si parla di centralizzazione quanto di conservazione. Almeno io la distinzione l'ho fatta...



OK, ma qui mi accodo al rilievo di xte. L'obbligo é la conservazione non tanto la centralizzazione.
 


Vabbe', mi sembra ovvio che se devi conservare i log li conservi in un 
posto solo.
O quando in casa devi conservare delle derrate deperibili le conservi in 
diversi frigoriferi specializzati?

 le direttive aziendali.
 
Questo certo, ma un conto è la scelta arbitraria di chi paga, un conto
è pensare che vi siano imposizioni di legge. Quanto agli admin, se ben
ho letto sospetto non siano interni, siano terze parti sotto contratto
e li bisogna vedere il contratto nel caso.
 
Per dire se io sono sotto SLA e mi propongono di aggiungerci un
pacchetto ignoto e sconosciuto ci penso molto ma molto bene prima di
dire ok, perché poi sono le mie terga a muovere e chiappar cetrioli
se qualcosa si rompe...


 Ecco, nella configurazione dei servizi AWS con Terraform, effettivamente si verifica il problema che hai sottolineato. Cioe' noi sviluppiamo le configurazione in un account diverso e poi gli chiediamo di replicarle nell'ambiente di staging e poi production.
 
Mamma mia... terribile.

 Almeno io la distinzione l'ho fatta...
 
Chiedo venia, ho seguito male il thread.



Ovvio che la centralizzazione sia una preferenza legittima e che sia 
anche legittima perche' la legge non lo vieta.
Mi sembra anche ovvio che se l'OP questo chiede, possa univocamente 
significare che nel suo documento della riservatezza, redatto dal 
titolare dei dati o chi per lui, ci sia scritto che i log vengono 
conservati in un posto solo.

 le conservi in diversi frigoriferi specializzati?
 
Non lo prescrive il medico e non è detto che il posto solo sia
opportuno, potrebbe esserlo, per altre ragioni (monitoraggio,
analisi, step successivi in caso di tentativi di tempering, ...)
ma non è detto lo sia, e potrebbe pure esser opportuno non creare
uno SPOF con potenziali problemi legali solo perché "va di moda".
 
Ps in effetti io ho frighi "specializzati", uno in cucina in cui
tengo la roba corrente, due in garage in cui in uno tengo scorte
extra che in cucina non mi stanno e nell'altro faccio stagionare
salami, pancettine e bresaole. Senza contare i due freezer nello
stesso garage. Come dire: non tutto si fa allo stesso modo e il
modo più comune non è detto sia il più opportuno, il migliore o
la via da seguire a prescindere.



Appunto: e' una tua preferenza pienamente legittima proprio perche' la 
legge, non imponendo un metodo specifico, lascia la liberta' di azione.
Cio' detto, mi sembra ovvio che chi gestisce il frigo debba ottemperare 
alle scelte del padrone del frigo.

 alle scelte del padrone del frigo.
 
Se chi gestisce il frigo è una terza parte con un contratto bisogna
vedere cosa prevede quest'ultimo. Già avere un setup di una certa
dimensione in mano a terzi non mi pare proprio il top, passi se i
terzi "ti fan la configurazione", ma monitoraggio e intervento come
dire... 



credimi , per motivi di sicurezza potrebbe essere addiritturara presscritto che i dati siano in luoghi differenti, se non proprio replicati in piú siti...

 Chiedo venia, ho seguito male il thread.
Infatti si é leggermente complicato. Comunque no, che io sappia la centralizzazione non é un must. E poi io ridonderei tutto di default...


 Mi sembra anche ovvio che se l'OP questo chiede
 
Ma non c'entrano niente gi articoli di lege con quello che l'OP vuol fare. Il log di accessi non c'entra nulla con i log che l'OP vuol centralizzare. Lui parla di log applicativi; roba che centralizzi con un ELK stack, per esempio.
 

 potenziali problemi legali solo perché "va di moda".
 
beh parliamone, eh. se hai un cluster con n nodi magari con gli 
applicativi che girano in una infrastruttura a container direi che 
centralizzare i log lo prescrive anche il medico. t'immagini andare a 
cercare un evento che è avvenuto in uno fra qualche centinaio di pod 
distribuiti in qualche decina di nodi?
ma più in generale, mentre non fatico a trovare ragioni più che valide 
faccio molta fatica a trovare controindicazioni. quella del spof è 
forzata, si può benissimo fare in modo che non lo sia.

 Ma non c'entrano niente gi articoli di lege con quello che l'OP vuol fare. 
 
Magari non ho prestato attenzione, ma l'OP parla esplicitamente di log 
applicativi e di sistema.

 applicativi e di sistema.
 
Infatti, ma non vuol dire che voglia salvare il log di accessi utenti ai fini di auditing soggetto alla legge. Menziona NewRelic, per esempio.
 

 Una bella ricetta per spararsi nei piedi, a mio parere.
 
Condivido il considerarlo una criticità, ma in grandi aziende dove l'IT 
non sia il core business si usa anche avere in casa la progettazione e 
la gestione, ma affidare l'esercizio all'esterno.
Situazione in cui è facile avere gli amministratori "esterni".
 
M.

 posto solo.
 
"Single Point Of Failure".
Magari li "usi" in un posto solo, ma da qualche altra parte ne hai una 
copia...  ;)
 
M.

 la gestione, ma affidare l'esercizio all'esterno.
 
Non e` vero. Io lavoro in una grande azienda dove l'IT non e` il core business e progettazione e gestione sono interne.
 


E invece è vero, lavoro in una grande azienda che si comporta 
esattamente come ho scritto, e non siamo i soli!  :)
 
M.

 si usa anche
 
Questa è la discriminante, non dico che sia solo e sempre come dico io, 
ma che sia "anche" così.  :D
 
M.

 esattamente come ho scritto, e non siamo i soli!  :)
 
Siete in pochi. Fidati.
 


Lo so bene, ma nel nostro caso e' questione di budget. Se no ovvio che saremmo tutti piu' felici con un team interno.


Non in Italia, fidati ... ...  :)
 
M.


Anche perchè altrimenti il fenomeno (tipicamente italiano) delle BR con 
i tecnici mandati a lavorare dal cliente sarebbe un fenomeno mooooolto 
più ridotto di quanto sembrerebbe leggendo questo NG!  :D
 
M.
 


decisamente no, non siete soli.

 
 
questo e' un ottimo argomento di discussione e sarebbe il caso di aprire 
un altro 3d.
 
cosa e' meglio ?
 
a) appalto del servizio IT
b) team interno
 
 
?????????????
 
io propendo per il team interno, il quale a sua volta si appoggia ad 
altri per aspetti circoscritti e specifici. esempio: le stampanti 
dipartimentali sono tutte della marca XXX e tutte con assistenza ogni 15 gg
 

Ok, ma non sai com'è l'infrastruttura dell'OP, magari lui ha giusto
una manciata di servizi, che conti sulle dita di una mano sola...
 
Non tutti sono saltati in certe mode solo perché il PFY di turno con
giacca, cravatta e macchinone ha detto che è il futuro, è cosa buona
e giusta ecc. Purtroppo TANTI, troppi l'han fatto, ma non tutti...



no infatti ci teniamo il buon vecchio monolith per ora. Trattasi sostanzialmente di alcune instance ec2, dove alcuni task asincroni (non essenziali) girano su AWS batch e Lambda. Non certo di microservice distribuiti su centinaia di nodi.