Инвентаризация на VPN сертификати: какво може да докаже регистърът на CA
Папка на сървъра, регистър на CA, списък за отмяна и таблица на сесиите отговарят на различни въпроси. Пазете ги отделно, когато инвентаризирате VPN идентичности.
Вашият шлюз приема клиентски сертификат, който никога не е виждал, защото това, с което е конфигуриран, е доверен издател, а сертификатът пристига по време на ръкостискането. Така протоколът трябва да работи и точно затова списъкът на папката на сървъра е лоша инвентаризация. Издателят знае какво е създал, сървърът знае какво се е свързало, а състоянието на отмяна знае какво е оттеглено. Инвентаризация, която смесва тези три записа, в крайна сметка твърди нещо, което никой от тях не е казал.
Шлюзът се доверява на издател, а не на списък с файлове
Валидацията сравнява представен сертификат с доверителна котва, така че идентичност, създадена вчера от същия издател, се свързва, без никога да е съществувала на диска на сървъра. Нищо не трябва да се копира, за да се случи това, и никой не трябва да го одобрява на ръка. Собствените записи на сървъра следователно описват пристигания, а не популацията от идентичности, които биха могли да пристигнат.
Обратната пропаст е също толкова неудобна. Една папка може да съдържа изтекли сертификати, отменени такива и идентичности, издадени за устройства, които така и не са били разгърнати. Броенето на файлове отговаря колко файла има, а това е въпрос, който никой не е задавал. Започнете вместо това от записите, които носят смисъл.
Четири въпроса, четири различни записа
Всеки тип запис отговаря добре на един въпрос и зле на останалите, затова доклад, който ги обединява, изглежда пълен, докато е грешен по конкретен начин. Таблицата по-долу ги подрежда по въпроса, който решават, а не по системата, която ги произвежда.
| Question you are answering | Where the answer lives | How quickly it changes | What it will never show |
|---|---|---|---|
| Was this identity ever created? | The issuer's issuance database | Only when something is issued | Whether the device still exists |
| Is a copy sitting on this host? | The paths you actually inspected | Whenever anyone copies files | Certificates that were never copied here |
| Has the issuer withdrawn it? | Published revocation state | When the issuer next publishes | Withdrawals that are not published yet |
| Is it connected right now? | The live session table | Continuously | Anything about past or future sessions |
Архив от публични сертификати не е тайна, тъй като не съдържа частни ключове, но също не е за споделяне. Субектите и имената на устройства разкриват оперативни подробности и докладът трябва да остане при аудиторията, която се нуждае от него. Частните ключове остават напълно извън инвентаризацията, защото инвентаризацията се нуждае от метаданни, а не от удостоверения.
Издател плюс сериен номер е единственият стабилен ключ
Субектите се рециклират, а имената на файловете се преизползват, така че име, което е идентифицирало едно устройство миналата година, може днес да идентифицира друго. Нито едното е ключ, и доклад, изграден върху което и да е от тях, в крайна сметка ще слее две идентичности в един ред.
Двойката издател и сериен номер идентифицира сертификата уникално и двете полета идват от самия сертификат. Запишете ги със субекта, датите на валидност, източника, от който е дошло копието, и отговорното лице или устройство. Добавете състояние на отмяна и разгръщане като отделни полета със собствени времена на наблюдение, защото сертификат в рамките на срока си на валидност не е автоматично упълномощен. Тези два факта живеят в различни системи и обединяването им скрива случая, в който идентичност е била оттеглена, докато файлът ѝ все още изглежда актуален.
Четете по един сертификат наведнъж
Шаблон със заместващ знак, който се разгръща през папка, не е пакетен интерфейс и крие кой файл кой изход е произвел. Четете метаданните поотделно за всеки сертификат и четете страната на отмяната от собствения ѝ артефакт. Справката за OpenSSL x509 изброява полетата, които тези опции отпечатват.
openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40За управлявана PKI с Easy-RSA направете заявка към базата за издаване чрез работния процес, който инструментът поддържа, вместо да предполагате оформление на папки, и пазете оригиналите само за четене, докато се сглобява инвентаризацията. Форматът на регистъра е достатъчно регулярен, за да се преброят валидните записи и да се изброят оттеглените, без да се отваря базата на ръка.
grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5Инвентаризация, която оцелява след следващото издаване
Еднократното изхвърляне на папка остарява в момента, в който бъде издаден следващият сертификат, затова изграждайте доклада от работния процес за издаване и го оставете да се обновява като част от нормалната работа. Това също прави доклада възпроизводим, което има значение, когато двама души не са съгласни какво е било издадено.
Използвайте резултата за решения за подновяване и извеждане от експлоатация, а не като упражнение с електронна таблица. Изтриването на местно копие не обезсилва отдалечените копия, които вече съществуват. Оттеглете идентичността чрез конфигурирания работен процес за отмяна и оторизация, след което запишете оттеглянето с датата му. Идентичност, която е изчезнала от сървъра, но все още е доверена на издателя, не е изведена от експлоатация, и точно тази разлика отделя точната инвентаризация от просто успокояващата.