Съхранение на VPN журнали: обвържете го с инцидента, не с число
Съхранението следва инцидента, съдържанието и политиката, а не универсален краен срок. Намерете всяко копие, спрете подробното събиране и водете кратък запис.
Никой всъщност не пита колко дълго да се пази VPN журнал; питат за какво служи журналът и отговорът на това определя датата. От един инцидент могат да излязат два файла с различен живот и третирането им като една политика поражда едновременно прекомерно съхранение и загуба на доказателства. Експорт за отстраняване на грешки, направен докато причината беше неизвестна, не е същият артефакт като ред в хранилище за мониторинг. Започнете от целта, после изберете датата.
Отговорете на четири въпроса, преди да изберете дата
Четири въпроса решават дали файлът остава: инцидентът още ли е открит, какво съдържа файлът, кой трябва да го чете и какво изисква приложимата политика. Отговорете в този ред и датата на съхранение се получава сама. Разсъждението се побира в таблица:
| Question | How it moves the answer |
|---|---|
| Incident state | An open investigation justifies a protected original; a closed one rarely does |
| Content | Connection identifiers, internal names and addresses raise the cost of a leak |
| Audience | Who retrieves it, and whether a redacted excerpt would serve them instead |
| Policy floor | The applicable service or organizational rule, which overrides a shorter reasoning |
Докато инцидентът е открит, пазете един защитен оригинал, за да сравните събития или да отговорите на въпрос от поддръжката по-късно, и му дайте писмени собственик и цел. За всеки извън екипа за реакция обикновено е достатъчен кратък редактиран откъс и той е много по-лесен за защита от пълния експорт. Оригиналът и откъсът са отделни артефакти с отделна аудитория и именно сливането им създава едновременно прекомерно съхранение и загуба на доказателства. Политиката поставя долна граница, така че ако изисква по-дълго от вашите разсъждения, политиката печели.
Затворете инцидента със запис, не с експорт
Напишете в тикета запис от четири реда: симптомът, клиентът и версията, единственият ред с грешка, който го разкри, и поправката. Не прикачайте нищо друго, защото експортът беше за вас, а записът е за следващия човек.
Записът също е по-вероятно да бъде прочетен: пълният експорт обслужва главно този, който го е снел, а той вече знае какво се е случило. Пазете записа там, където ще се търси при следващия инцидент, което обикновено означава тикета, а не папка, наречена на дата. Номер на случай може да носи препратката, ако записът трябва да е проследим, без да разкрива идентификатор на връзка. Ако въпросът още е открит, оригиналът остава под правилото за защитено копие по-горе; щом записът съществува, всичко останало може да отиде.
Намерете всяко копие, преди да изтриете едно
Проверете папката за експорт, после журнала за прозореца на инцидента, после прикачените файлове към тикета, после каталога за резервни копия, после хранилището за мониторинг. Ако същият идентификатор на връзка се появи на пето място, инвентарът е бил грешен. Журналът е обичайната изненада, защото продължи да събира, докато четяхте експорта.
Използвайте поддържания път за ротация и изтриване, вместо да разкачате файлове на ръка. Файл, който все още е отворен, запазва мястото си, след като записът в директорията изчезне, така че изтриването изглежда пълно и не освобождава нищо. Това е бъг в съхранението с етикет за поверителност и не постига нито една от двете цели.
Спрете събирането, преди да проверите изтриването
Спрете временното подробно събиране през приложението, което го притежава, а не като редактирате изходния му файл. Забравена настройка за отстраняване на грешки продължава да пише нови записи, след като старите бъдат премахнати, което тихо отменя току-що свършената работа. Проверете действителното ниво на журналиране, а не стойността, която си спомняте, че сте задали. След това потвърдете, че останалото е защитено и че само предвидените хора могат да го извлекат.
Принципът е минимизиране на данните: пазете това, което заявена цел изисква, толкова дълго, колкото е нужно, и нищо повече, както насоките за поверителност RFC 6973 го формулират. Файл, пазен без цел, е отговорност с времеви печат. Решението е приключено, когато можете да назовете файла, целта му, собственика му и крайната му дата.