Как да документирате одобрения за достъп до VPN без история на сърфирането

Два екипа искат един и същ документ и влагат различен смисъл в него. Проверяващият иска доказателство, че определен човек е одобрил роля до определена дата, докато мрежовият екип разполага с дневник на защитната стена, пълен с дестинации, и предполага, че това е достатъчно. Не е, и затова папките с одобрения се пълнят с имена на хостове и все пак се провалят на първия въпрос от одита. Това, което наистина ви трябва, е малко и нищо от него не изисква да записвате къде някой е сърфирал.

Обемът на записа следва три условия: дали одобрението се дава на човек или на роля, дали правото може да надживее трудовото правоотношение на човека и дали договор или рамка посочва прегледа на достъпа като изискуемо доказателство.

Започнете от въпроса на проверяващия, а не от връзката

Запишете въпроса, който одиторът би задал на глас, преди да изберете дори едно поле. Кой е одобрил достъпа за тази самоличност, до какво, между кои дати и кой е трябвало да го премахне накрая. Всяко поле във формуляра трябва да отговаря на част от това изречение, а всичко, което не го прави, е инвентар, за който току-що сте поели задължението да го защитавате.

Този тест премахва по-голямата част от онова, което се добавя по навик. Списъци с дестинации, DNS заявки, графики за използване на приложения и снимки на екрана на жива сесия — всички те описват поведение. Поведението не е одобрението и събирането му премества файла в много по-висок клас на чувствителност, което работи срещу целта, с която сте започнали.

Три условия решават колко да пазите

Одобренията за конкретен човек се нуждаят от самоличност и крайна дата. Одобренията за роля се нуждаят от ролята, обхвата, който тя дава, и собственика на съвкупността, защото изброяването на четиридесет души в един ред създава четиридесет записа за поддръжка и четиридесет шанса да се пропусне напускане. Когато правото може да надживее трудовото правоотношение, добавете собственик на премахването и периодичност на прегледа, тъй като крайна дата в електронна таблица рядко кара някого да действа.

Когато рамка посочва прегледа на достъпа като изискуемо доказателство, пазете документа, който процесът на преглед вече цитира. Изграждането на паралелно копие за VPN екипа е начинът, по който две версии на едно и също одобрение стигат до разминаване относно крайна дата.

Полетата, които носят решението

Работещият набор е кратък: одобрената самоличност, заявителят, одобряващият, ролята или обхватът на ресурса, причината в един ред, прозорецът на действие, собственикът на прегледа или премахването и указател към тикета, където заявката е обсъждана. Позовавайте се на устройството или идентификационните данни с несекретен идентификатор като инвентарен номер или субект на сертификат, никога с частния ключ или паролата, които са били използвани.

Отнасяйте се към резултата като към лични данни, дори когато не съдържа дестинации. Запис, който казва, че този посочен служител е имал административен достъп до финансовия сегмент шест месеца, е чувствителен сам по себе си, затова определете кой може да чете папката и задайте срок на съхранение за административната цел, вместо да наричате файла анонимен.

Откъде данни за сърфиране се промъкват в делото с одобрението

Три изтичания обясняват по-голямата част от това. Тикет в сервизното бюро съдържа снимка на екрана на клиентския прозорец за връзка, някой поставя експорт от SIEM за контекст или отчет за инвентаризация се прикача към одобрението, защото тогава обединяването е било лесно. Всяко приложение добавя поведение към файл, на който му е трябвало само решение. Щом снимката влезе, проверяващият започва да пита какво е достигал потребителят, и файлът трябва да бъде прекласифициран.

Заменяйте прикачените файлове с указатели, където инструментът позволява. Ако политиката настоява за прикачен файл, поискайте текста на решението и нишката на заявката, а не записа на сесията, и премахнете останалото преди файлът да бъде запазен. Собственото съобщение на одобряващия обикновено е най-доброто доказателство и най-малко разкриващото.

Проверете обхвата без следата

Политиката на шлюза е това, което превръща одобрението в достъп, затова я тествайте директно. Влезте с профил в рамките на одобрения обхват и достигнете разрешен ресурс, след това опитайте дестинация извън обхвата и потвърдете отказа, като използвате клиента и метода, които политиката очаква, а не раздел в браузъра на същия хост.

Мониторингът на наличността и диагностиката на инциденти могат да пазят собствена видимост, при собствен срок на съхранение и собствен списък за достъп. Именно разделянето на тези две цели ви позволява да отговорите на проверяващия, без да предавате следа от сърфиране, и запазва диагностиката полезна, когато нещо наистина се счупи.

Какво да проверите преди следващия преглед

Уверете се, че формулярът отговаря на изречението на одитора и на нищо повече. Проверете дали всеки ред носи одобряващ, прозорец и собственик на премахването. След това погледнете собствения списък за достъп на папката и се запитайте дали е по-малък от базата потребители на VPN.

Последната стъпка е тази, която хората прескачат. Вземете изтекло одобрение и го проследете до доставчика на самоличност, за да видите дали профилът наистина е бил деактивиран. Ако самоличността е още активна, записът е бил точен, а процесът не.