Сенчесто ИТ: превърнете откриването в отговорна собственост

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

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

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

Определете границата, преди да събирате сигнали

Сенчестото ИТ е състояние на управлението, а не категория по същество несигурни продукти. Реномирана услуга за сътрудничество може да е неуправлявана, когато служителите създават лични работни пространства. Личен лаптоп може да е легитимен при контролирана уговорка за използване на собствени устройства. Обратно, закупена услуга все пак може да е извън ефективното управление, ако никой не контролира нейните администратори или процеса при напускане.

Гледайте отвъд непознатите имена на софтуер. Релевантните примери включват:

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

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

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

Изградете картина от няколко източника

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

Използвайте допълващи се източници и запазвайте произхода на всяка констатация.

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

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

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

Превърнете всяка констатация в запис за собственост

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

За всяка потвърдена употреба документирайте:

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

Бизнес собственикът обосновава нуждата и координира приемливата употреба. Техническият отговорник управлява конфигурацията, достъпа, интеграциите и извеждането от употреба. Сигурността оценява риска; специалистите по снабдяване и поверителност преглеждат въпросите в своята компетентност. В малка организация тези отговорности може да са на един и същ човек, но те трябва да останат изрични.

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

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

Проверявайте достъпа чрез OAuth отделно от използването на приложението

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

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

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

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

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

Приоритизирайте според експозицията и бизнес зависимостта

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

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

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

Документирайте конкретен сценарий на риска, а не „риск от сенчесто ИТ“. Например: „Бивш служител запазва администраторски права в работното пространство и може да експортира оферти за клиенти.“ Това твърдение насочва към собственик, промяна в контрола и тест.

Откриването не е автоматично доказателство за нарушение. Ако констатациите сочат неразрешено разкриване или компрометиране, преминете към процеса за управление на инциденти, като запазите релевантните журнали. Когато са засегнати лични данни, оценката за уведомяване зависи от обстоятелствата и от организационната роля съгласно членове 33 и 34 от ОРЗД, а не просто от това дали инструментът е бил одобрен.

Изберете третиране, което запазва бизнес нуждата

Всяко решение се нуждае от собственик, обосновка, критерии за завършване и последващи действия. На практика са полезни четири вида третиране.

Одобряване и поставяне под управление

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

Прегледайте доставчика и договора, когато е приложимо. Ако доставчикът обработва лични данни от името на организацията, оценете изискваните уговорки с обработващия съгласно член 28 от ОРЗД. Уговорките за международно предаване изискват отделна оценка; избраният регион за хостинг не решава всеки въпрос. Мерките за сигурност по член 32 се основават на риска и не са универсален контролен списък, който се изпълнява с една настройка.

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

Замяна с подходяща алтернатива

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

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

Премахване на необоснованата употреба

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

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

Разрешаване на контролирано временно изключение

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

Практически пример: ИИ асистент за срещи

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

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

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

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

Предотвратете следващото сляпо петно с използваем процес за заявки

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

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

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

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

Направете доказателствата полезни за ISMS

ISO/IEC 27001 се отнася до система за управление на информационната сигурност с определен обхват. Констатациите за сенчесто ИТ могат да информират управлението на активите, прегледа на доставчиците, контрола на достъпа, оценката и третирането на риска. Изборът на контроли остава основан на риска; списъкът с приложения не е нито ISMS, нито доказателство, че контролите функционират.

Поддържайте обхвата на откриването, оценката, решението за третиране, доказателствата за внедряването и проверката на ефективността разграничени. Затворена заявка с текст „премахнато“ е по-слабо доказателство от отнет достъп и тестван резултат. Приемането на риска трябва да посочва кой е имал правомощието да го приеме и кога трябва да бъде преразгледано. Сертификацията сама по себе си не установява съответствие с ОРЗД.

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

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