Puncte:1

Cum se rezolvă problema cu puiul sau ouăle cu certificatele TLS ale clientului pe o gazdă fizică?

drapel pe

Nu înțeleg cum să rezolv problema găinii sau a ouălor la automatizarea instalării serverelor.

Am o serie de servere care pot fi reconstruite prin PXE. Când o mașină este reconstruită, aceasta încarcă toate setările de care are nevoie, inclusiv certificatul său privat pe care îl va folosi pentru a se autentifica atunci când va folosi mai târziu diferite servicii, de pe un server Apache. Acest server Apache identifică clienții după adresele lor IP pentru a le servi fie configurația sau certificatul destinat unui anumit server, fie refuza să-l deservească.

Cu toate acestea, adresa IP a unui client ar putea fi falsificată. La fel și pentru adresa MAC, dacă la un moment dat adaug și acest tip de verificare.

Pentru a-și prelua configurația și certificatul privat în siguranță, mașina care pornește prin PXE ar trebui să aibă deja un certificat pe care l-ar putea folosi atunci când comunică cu serverul Apache. Acest lucru, totuși, nu pare posibil, deoarece o mașină care pornește de la PXE este fie proaspăt nouă, fie își va formata oricum discul în timpul instalării.

Am pierdut ceva? Cum pot identifica o mașină nouă, fără riscul de falsificare?

Ar trebui să folosesc o cheie USB întotdeauna conectată care conține cheia privată? Sau mai sunt si alte optiuni?

drapel in
Părțile private ale unui certificat nu ar trebui să treacă niciodată peste fir, în primul rând. TPM poate fi folosit pentru a recrea în mod fiabil o cheie privată, care apoi generează cheia publică, care apoi poate fi folosită pentru a crea un certificat.
drapel pe
@NiKiZe: Nu sunt sigur cum funcționează. Imaginează-ți că am o mașină nouă, fără sistem de operare instalat. Cum pun un certificat în TPM în primul rând? Ce vrei să spui prin faptul că TPM poate recrea o cheie privată? De unde știe ceva despre CA?
drapel in
Nu pui prea mult în el în primul rând, îl activezi și îți oferă un blob permanent aleatoriu - atâta timp cât nimic din procesul de pornire nu se schimbă, dacă se întâmplă, atunci se schimbă și cheia.
Puncte:2
drapel cn

Îl folosim pe cel al maistrului plugin bootdisk în acest scop. Nu presupun că este modul corect sau unic, este ceea ce folosim cu succes.

De fiecare dată când o gazdă trebuie să fie (re)provizionată, este generat un token de scurtă durată și este păstrat în baza de date cuplată la gazdă. Acest token intră într-un fișier iso cu binarul ipxe și un script care descarcă fișierul kicstart de la gazda de furnizare numai dacă oferă jetonul potrivit ca identificator. Odată ce gazda este furnizată, jetonul este șters. După un anumit (reglabil, din partea de sus a capului meu este implicit la 60 de minute) jetonul este invalidat.

Acest lucru funcționează atât cu bios-ul, cât și cu firmware-ul uefi și nu este nevoie de pxe, doar http(e), astfel încât să puteți avea cu adevărat implementări pe internet cu puține modificări (la îndemână pentru implementarea hardware-ului în locații la distanță).

drapel pe
Dacă un hacker pune mâna pe token *chiar înaintea* serverului care este furnizat, atunci hackerul va avea acces la resurse, dar în timp ce o face, furnizarea va eșua, iar administratorii de sistem vor fi alertați că ceva s-ar putea să se întâmple urât. Are sens, într-adevăr.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.