Заједнички CA, одвојена врата: једна услуга по датотеци одобрења

Сертификат који се валидира према заједничком ауторитету прошао је тест поверења, а не тест чланства. Те две одлуке се често стапају јер се обе дешавају у тренутку повезивања, а стапање остаје невидљиво док у услугу не буде примљен неко ко тамо не би требало да буде. Решење није други ауторитет; то је друга одлука, донета по услузи и записана тамо где је демон чита. Држите их одвојено и већина забуне у овој области нестаје.

Поуздан ланац не говори ништа о чланству у услузи

Две услуге могу прихватати исту издавачку хијерархију и ипак имати различите популације. Један лаптоп припада првој и не сме да достигне другу, док други клијенти исте хијерархије заиста припадају тамо. Уклањање ауторитета из те услуге закључало би све који је легитимно користе, па је посао одобрење, а не поверење.

Помаже да замислимо две брави на једним вратима. Сертификат отвара спољну браву, а одлука по услузи отвара унутрашњу; ниједна не замењује другу. Услуга само са спољном бравом уопште не спроводи чланство, она само проверава идентитет. Запишите обе одлуке пре било какве измене, јер политика која постоји само у облику радне везе не може се ревидирати. Оно што следи тиче се унутрашње браве.

Претворите необавезна преклапања у капију одобрења

Директоријум клијентске конфигурације обично је погодност: датотеке у њему преклапају поставке за клијенте које именују, а клијент без датотеке једноставно ради са подразумеваним вредностима сервера. Једна директива претвара ту погодност у капију, тако да датотека која недостаје значи одбијену везу.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Заједничко издање OpenVPN 2.6 ccd-exclusive документује на својој страници приручника управо тај услов, а тражење именоване датотеке зависи од ефективног идентитета клијента. Друге градње и сервери којима управљају производи могу се разликовати, па потврдите инсталирану верзију пре него што се ослоните на исту семантику другде.

Третирајте горњу путању као пример и проверите стварно распоређени изглед, уместо да правите директоријум који је измислио неки водич. Оставите постојеће провере сертификата, провере идентитета сервера и аутентификацију налога тачно онаквима какве су биле, јер фрагмент додаје услов и ништа не уклања. Припремите промену пре продукције, јер одбијање подигнуто на погрешном месту изгледа као квар сертификата и шаље истрагу ка ауторитету. Затим потврдите да линија записа за одбијеног клијента именује конфигурациону датотеку која недостаје, а не ланац.

Један директоријум по услузи, а не један дељени списак

Чланство припада услузи која га спроводи, па свака услуга држи сопствени директоријум и сопствене датотеке. Усмеравање две услуге на један списак чини да деле чланство без обзира да ли је то неко намеравао, а насталу промену је тешко пратити до одлуке. Заједнички ауторитет може остати заједнички; датотеке одобрења не могу. Њихово раздвајање такође значи да грешка у једној услузи не може тихо проширити другу.

Унос DEFAULT је случај који заводи људе. Он даје резервне поставке када именована датотека није пронађена, али то није именована датотека коју капија захтева, па не може сам да прими клијента. Тестирајте клијента који уопште нема унос и потврдите одбијање; ако је тај клијент примљен, резерва се примењује и ccd-exclusive није на снази у тој инстанци.

Ефективни идентитет одлучује која се датотека чита

Претрага користи идентитет са којим се клијент стварно аутентификовао, што је обично заједничко име сертификата. Када сервер такође проверава корисничко име и лозинку и пресликава то име у заједничко име, датотека мора да одговара аутентификованом корисничком имену. Неподударање оставља директоријум пун вероватних назива датотека који се никада не бирају.

Читање је друга половина. Демон обично спусти привилегије након покретања, па смањени налог треба приступ читању директоријума и сваког уноса у њему. Клијенти не смеју моћи да створе сопствени унос кроз било коју путању која се може писати, јер самоуслужно одобрење потпуно поништава механизам. Проверите дозволе за монтирање и дељење, а не само режим датотеке, јер директоријум који изгледа затворен за један налог може бити отворен за други. Затим потврдите који налог покренути процес стварно користи, а не који налог помиње unit датотека. То двоје је исто само када их ништа друго није променило.

Посматрајте одбијање, одобрење и опозив одвојено

Пробајте идентитет који припада услузи и потврдите да се повезује. Пробајте важећи сертификат без уноса и потврдите да је одбијен. Пробајте идентитет одобрен другој услузи и потврдите да овде није одобрен. Запишите инстанцу услуге и ефективни идентитет уз сваки резултат, јер резултат без тог контекста нико други не може да репродукује.

Повлачење је одвојена операција од опозива. Уређивање датотеке одобрења уклања право на једну услугу док идентитет остаје важећи свуда другде, док компромитовани кључ захтева одговор организације на опозив. Унапред одлучите шта се дешава са већ успостављеним сесијама, јер ни уређивање директоријума ни списак опозива не завршавају их саме по себи.

Одобрење је такође само прва капија. Придруживање услузи не говори ништа о подмрежама, базама података или управљачким интерфејсима иза ње, а та политика ресурса мора се написати и тестирати одвојено.