Предаване на достъп за тестване на сигурността: обхват, акаунти и отнемане

Тестер иска адрес на шлюз, подробности за вътрешен DNS и данни за VPN, а заявката се препраща към вас с тема „нужен е достъп“. Самата заявка не ви казва дали това е вътрешна оценка, тест на приложение с удостоверяване или ангажимент за публичен уебсайт, при който някой е разбрал погрешно обхвата. Изпълнете предаването като последователност с проверка на всяка стъпка и спрете при първата порта, която не се отваря. Така неясната заявка се превръща в нещо, което можете да оторизирате, да предоставите и по-късно да отнемете.

Започнете с оторизацията, не с данните за достъп

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

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

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

Назовете гледната точка и целите

Гледната точка е въпросът, на който оценката се опитва да отговори, и тя определя пакета за достъп повече от всеки инструмент, който тестерът планира да използва. Публичният тест без удостоверяване се нуждае от URL и времеви прозорец. Тестът с удостоверяване се нуждае от отделни акаунти за конкретните роли в обхвата, а вътрешната оценка — от определена входна точка с ясни диапазони на целите.

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

Дайте TLS името на хоста заедно с URL. Голият IP адрес принуждава тестера да гадае името, а погрешното име произвежда сертификатни грешки, които се докладват като констатации, а не като грешка в предаването.

Издайте отделни самоличности с краен срок

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

sudo useradd -m -e 2026-12-31 tester01
sudo passwd -S tester01
id tester01
lastlog -u tester01

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

Полето за срок е последна защита, не планът. Някой все пак трябва да премахне мрежовия път и ролята на приложението накрая, защото изтекъл вход в мрежа, която все още е достъпна, не е отнет достъп.

Докажете, че предаването работи, преди прозорецът да се отвори

Изпълнете първия скок на тестера сами, от позиция възможно най-близо до неговата. Разрешете името, проверете самоличността на сертификата и потвърдете, че пътят стига до предвидения адрес, а не до съседен.

dig +short app.example.com
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates
ip route get 10.60.0.25

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

Изпратете оперативния контакт, разрешените часове, изключените действия и условията за спиране заедно с данните за достъп. Тестер, който не може да се свърже с никого в 02:00, ще вземе решение, което не сте оторизирали, и това решение ще бъде описано в доклада, сякаш е било в обхвата.

NIST SP 800-115 описва техническата оценка като планирано тестване, последвано от анализ и смекчаване, и точно тази форма следва настоящото предаване. Портитите по-горе са редакционни решения за инженер по поддръжка, а не контролен списък, цитиран от тази публикация.

Затворете ангажимента, като премахнете достъпа

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

sudo passwd -l tester01
sudo pkill -u tester01
ss -tn state established '( sport = :443 )'

Уредете всички запазени тестови данни, после проследете отстраняването чрез процеса за докладване, договорен в началото. Докладът трябва да посочва средата, нивото на достъп, обхвата и ограниченията, защото записва констатации от една оценка и не е постоянно твърдение, че сайтът е сигурен.

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