Достъп до VPN чрез служебен акаунт: сертификат или споделен вход
Сравнете машинен сертификат със запазена парола за достъп до VPN без надзор и поставете реалната граница на правата в политиката, която се изпълнява след влизане.
Два дизайна покриват почти всяка настройка на VPN без надзор: споделен човешки вход, пазен в скрипт, или машинен сертификат, вързан към хоста. Те се провалят на различни места и това е по-важно от скоростта на настройка. Запазената парола се чупи, когато собственикът ѝ я смени или напусне; сертификатът се чупи, когато изтече или когато хостът бъде пресъздаден без ключа. Три условия решават коя цена можете да понесете и нито един от двата дизайна не ограничава нищо, докато политиката за оторизация не го направи.
Започнете от задачата, не от акаунта
Задачата определя границата: кои дестинации, кои услуги, в кои часове, колко дълго може да работи сесия. Тунелният маршрут е само половината от тази граница. Шлюзът решава дали сесията е разрешена; ресурсът зад него решава какво може да прави сесията. Първо напишете списъка, с посочен собственик, защото и двата дизайна на идентичност трябва да го удовлетворят.
Пазете автентикацията и оторизацията отделно, докато го записвате. Автентикацията отговаря кой се свързва; оторизацията отговаря до какво може да стигне сесията след това. RADIUS носи втората част като атрибути като Filter-Id, Framed-IP-Address, Session-Timeout и Class, а шлюзът ги прикача, щом входът успее. Дизайн, който сменя входа и оставя оторизацията непокътната, не е ограничил нищо.
Споделен човешки вход: паролата става границата
Повторното използване на човешки акаунт е най-бързият път и този, който остарява най-зле. Удостоверението е парола, така че свършва в скрипт, файл с околна среда и конфигурация на планировчик, и всяко копие се нуждае от ротация. Когато собственикът я смени в петък, задачата се проваля при следващото изпълнение и никой не гледа.
MFA е мястото, където този дизайн обикновено се срутва. Скриптът не може да отговори на push заявка, затова акаунтът се изключва от политиката, а това е точно акаунтът, който нападателят би избрал. Изключенията, заобикалянето на доверени местоположения и освобождаванията по акаунт се умножават и никое не е видимо за следващия човек, който чете настройките на наемателя.
Приписването е другата цена. Всяка сесия в журнала на шлюза носи същото потребителско име, затова нощната синхронизация не може да се разграничи от работата на човека, който я е написал, и отнемането на задачата означава отнемане на този човек.
Машинен сертификат: идентичност, вързана към хоста
Сертификатът сменя въпроса от това какво знае акаунтът към това какво е хостът. С EAP-TLS клиентът представя сертификат и доказва притежание на съответния частен ключ; сървърът за политики съпоставя субекта или компютърния акаунт с група и прилага политиката за тази група. Без подкана, без споделена тайна, седяща в текстов файл.
Границата, която създава, е по-тясна, отколкото хората очакват. Сертификатът удостоверява хоста, не задачата, и всеки с root или локални администраторски права може да използва този ключ на този хост. Пазете ключа там, където платформата го защитава: неекспортируем в хранилището за сертификати на Windows, с подкрепа от TPM, където профилът позволява, или файл 0600, притежаван от root, в Linux. Компрометирането на хоста е компрометиране на удостоверението.
Изтичането е повтарящият се провал. Сертификат, който изтича в неделя, спира задачата в неделя и шлюзът обикновено съобщава обща грешка при автентикация, вместо да посочи датата. Проверявайте датите от хоста на задачата като част от runbook:
openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcertsОтнемането се нуждае от път, който шлюзът проверява. OpenVPN чете CRL чрез опцията crl-verify, а strongSwan зависи от CRL или OCSP според това как е изграден профилът на връзката. Ако нито едно от двете не е свързано, премахването на хост означава да се чака сертификатът да изтече.
Три условия, които решават между тях
Правете сравнението срещу платформата, която имате, а не срещу референтен дизайн.
Първо условие: може ли шлюзът да оторизира машинна идентичност? Ако само съпоставя потребителско име от RADIUS с потребител в директорията, сертификатът удостоверява хоста и после засича при оторизацията. Второ условие: има ли задачата нужда от достъп до ресурс, който носи само потребителски акаунт, като картографиран дял или лиценз за място? Тогава машинната идентичност не може да замести и честният отговор е отделен потребителски акаунт с ограничена политика. Трето условие: кой може да ротира удостоверението без човек в цикъла? Автоматичното записване прави сертификатите евтини за поддръжка; парола, известна на един човек, не е.
| Constraint | Machine certificate | Dedicated user account with stored secret |
|---|---|---|
| Unattended login | Private key proof, no prompt | Only if the account is exempted from MFA |
| Resource expects a user identity | Works only when the resource accepts computer accounts | Matches the access a person would have |
| Rotation | Re-enrollment, often automated | Secret change plus redeploy of every copy |
| Revocation speed | Tied to CRL or OCSP refresh | Disable the account, immediate |
Четете таблицата като списък с цени, не като класация. Колоната със запазена тайна печели по скорост на отнемане и по съвместимост с ресурси, които разбират само потребителски акаунти; колоната със сертификат печели по ротация и по това, че не отслабва MFA, за да работи скрипт.
Поставете границата в политиката, след автентикация
Каквато и идентичност да изберете, границата на правата принадлежи на политиката, която се изпълнява след автентикация. В NPS мрежовите политики се оценяват по ред и първата политика, която съвпада по всяко условие, прилага своите настройки, така че широка политика, поставена над тясна, решава резултата независимо какво представя клиентът. Microsoft документира модела на условия и настройки в своя преглед на NPS политиките.
Дайте на задачата собствена група или условие на политика, основано на нещо, което машинната идентичност носи: шаблон за сертификат, идентификатор на станция за повикване или адрес от отделен пул. После ограничете сесията с атрибути: Filter-Id за ролята, към която вашият шлюз я съпоставя, кратък Session-Timeout, за да се преавтентикира заседнала задача, вместо да държи сесия с дни, и Framed-IP-Address от пул, който филтрирате от другата страна. Оторизацията на приложението остава отделна: тунел до сървър за бази данни не е разрешение да четете таблица в него.
Проверете отказите, после планирайте премахване
Работещият достъп не доказва нищо за най-малките права. Проверете отказите вместо това: свържете се с идентичността на задачата и посегнете към дестинация извън списъка, отворете втора паралелна сесия, ако шлюзът трябва да позволява само една, и повторете входа след отнемане на удостоверението.
После потвърдете същата сесия на две места. Журналът на шлюза показва идентичността, която се е автентикирала; журналът на сървъра за политики показва коя политика е съвпаднала и какви атрибути е върнала. В OpenVPN сървърът записва общото име на сертификата, а ipsec statusall в strongSwan отпечатва установения тунел с използваната идентичност. Ако двата журнала не са съгласни за идентичността, политиката съвпада с нещо друго, а не с това, което предполагате.
Премахването е част от дизайна, не спринт за почистване. Запишете всичко за изтриване (сертификат или акаунт, членство в група, мрежова политика, запис в пул, правило за защитна стена на целта) и го изпълнете веднъж, докато задачата е лесна за пресъздаване.
Ако започвате днес, работете в този ред: напишете списъка с ресурси, изберете идентичността с трите условия, поставете границата в политиката и упражнете един отказ, преди задачата да влезе в употреба.