Одитен дневник и достъп на поддръжката: кой, какво, кога

Представете си Марта, офис мениджър в компания с 250 души, два етажа и паркинг. Вторник, 9:50. В рамките на десет минути ѝ пишат трима души: резервациите им на бюра са освободени като неявявания, въпреки че са пристигнали в 9:40, както всяка седмица. Нещо се е променило и никой не помни да го е променял. В организацията има четирима администратори плюс интеграция, която синхронизира потребителите от фирмената директория. Въпросът е прост: кой какво е променил и кога?

Седмица по-късно длъжностното лице по защита на данните ѝ задава друг въпрос за годишния преглед на доставчиците: „Доставчикът на софтуера разглеждал ли е данните ни тази година и ако да, кога?“ На такива въпроси често се отговаря с документ с политика. Марта би искала да отговори със списък.

Тази статия показва как одитният дневник на Desk & Park отговаря и на двата въпроса, стъпка по стъпка, и какво не прави.

Стъпка 1: отворете одитния дневник и намерете промяната

Администраторите намират дневника в Одитен дневник. Най-отгоре има три брояча: събития през последните 24 часа, предупреждения и критични събития. Отдолу е таблица с най-новите записи, като най-новите са първи, със следните колони:

• Дата и час: кога се е случило.
• Ниво: Информация, Предупреждение или Критично.
• Извършител: имейл адресът на този, който е направил промяната, с ролята му отдолу, или „system“ за автоматичните действия.
• Действие и Ресурс: какво е направено и с какъв вид обект.
• Детайли: засегнатите стойности, например role: MEMBER → ADMIN при смяна на роля.
• IP адрес: откъде е дошла заявката.

Марта въвежда „policy“ в полето за търсене („Търсене по извършител, действие или детайли...“). Записът е там: вчера в 17:12 един от администраторите е променил правилата за резервиране и е съкратил срока за чекиране. Записът съдържа стойностите преди и след промяната, така че последвалият разговор е за това дали новият срок има смисъл, а не за това кой го е направил. (Ако настройвате този срок, нашата статия за призрачните резервации и автоматичното освобождаване обяснява компромиса.)

Какво се записва

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

Всеки запис съхранява извършителя и ролята му, действието и засегнатия обект, резултата, стойностите преди и след, IP адреса и user agent на браузъра.

Филтърът по ниво

Смените на роли, деактивиранията и изтриванията се отбелязват като Предупреждение. Неуспешните действия са Критично. Филтрирането по ниво е най-бързият седмичен преглед: задайте филтъра на „Предупреждение“, прегледайте кой е повишен или деактивиран и сте готови.

Стъпка 2: потокът за сигурност, обединен в същата таблица

Промените в съдържанието са само половината от картината. Същата таблица показва и потока за сигурност: успешни и неуспешни влизания, заключвания след повтарящи се неуспехи, изискани и неуспешни двуфакторни кодове, включване или изключване на двуфакторното удостоверяване, нулиране и смяна на пароли, както и повторно използване на отнет токен на сесия. Неуспешно влизане, заключване или повторно използван токен се показват като „Критично“; изключването на двуфакторното удостоверяване се показва като „Предупреждение“.

За Марта това означава едно място, на което да гледа. Ако акаунт е бил заключен в 7:00, а ролята му е сменена в 7:05, двата реда стоят един до друг.

Стъпка 3: отговорете на длъжностното лице по защита на данните – достъпът на поддръжката се записва в собствения ви дневник

Сега вторият въпрос. Когато операторът на платформата – екипът, който поддържа Desk & Park – отвори изгледа за поддръжка на вашата организация, за да помогне по заявка, системата записва запис в собствения одитен дневник на вашата организация. Той се появява като TENANT SUPPORT ACCESS, с имейл адреса на оператора, часа и IP адреса.

Така Марта въвежда „support“ в полето за търсене и получава отговора като списък: кога някой от страната на доставчика е отварял данните на организацията и кой е бил той. Това е разликата между „имаме политика“ и „ето записа“. Записът попада във вашия дневник, а не в дневник, който само доставчикът може да чете. Тъй като страницата показва най-новите записи, Марта прави тази проверка ежемесечен навик и пази експорта, вместо да чака годишния преглед.

Къде се съхранява дневникът и колко време остава

Всяка организация в Desk & Park има собствена база данни PostgreSQL със собствена роля за вход в базата данни, а одитният дневник се съхранява там, заедно с вашите потребители, карти и резервации. Обясняваме защо тази архитектура има значение в защо данните за работното ви място се нуждаят от изолирана база данни. Потокът за сигурност се съхранява от услугата за вход на платформата и ви се показва филтриран за вашата организация.

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

• Нощни криптирани резервни копия на базата данни на организацията, които администраторът на организацията може да изключи.
• Експорт в JSON на данните на организацията, за администраторите.
• Искане за изтриване на цялата организация.

Условията за обработка на данни са в DPA.

Практични съвети

• Дайте на всеки собствен администраторски акаунт. Общият вход „admin@“ прави колоната „Извършител“ безполезна. Един човек, един акаунт.
• Правете седмичен петминутен преглед. Филтрирайте по „Предупреждение“, след това по „Критично“. Търсете смени на роли, които не сте очаквали, и повтарящи се неуспешни влизания.
• Пазете копие, ако ви трябва по-дълга история. Бутонът Експортиране на CSV изтегля записите, заредени в момента на страницата, които са най-новите. Ако одиторите ви искат повече от година, експортирайте по редовен график и съхранявайте файловете заедно с другите си записи за съответствие.
• Добавете достъпа на поддръжката към прегледа на доставчиците. Веднъж месечно потърсете „support“, експортирайте резултата и го архивирайте за годишния преглед. Отнема минута.
• Съчетайте дневника със силно влизане за администраторите. Дневникът ви казва какво се е случило; двуфакторното удостоверяване за всеки администраторски акаунт прави по-малко вероятно да се случи нещо лошо. Вижте SSO, ключове за достъп и двуфакторен вход.

Обхват: какво не прави

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

Често задавани въпроси