Журнал "Системы Безопасности" № 6‘2024

К О М П Л Е К С Н А Я Б Е З О П А С Н О С Т Ь , П Е Р И М Е Т Р О В Ы Е С И С Т Е М Ы 54 паролей, отзыва паролей по команде адми- нистратора, контроля количества попыток ввода пароля и др. делает атаки через под- бор паролей быстрыми и очень эффектив- ными. Во-вторых, по оценке автора, большая часть программных средств физической безопасно- сти работает под управлением ОС Microsoft Windows. В любом программном обеспечении есть ошибки и уязвимости, ОС Windows не исключение. Производитель регулярно выпус- кает патчи безопасности для своих продуктов. Но, будучи установленным три, пять, а то и десять лет назад, ПО систем безопасности работает зачастую под управлением устарев- ших и не поддерживаемых производителем версий ОС. Кроме того, в свете текущей гео- политической ситуации в Российскую Федера- цию официально актуальные версии ОС и обновления не поставляются, а 8 апреля 2022 г. ФСТЭК принял решение приостановить действие сертификатов на все программное обеспечение Microsoft (как и многих других иностранных поставщиков). Таким образом, количество уязвимостей в решении становится больше от года к году, и это только вопрос времени, когда очередной вирус ими вос- пользуется. Другая неприятная особенность таких систем – возможность полного доступа одного пользова- теля ко всем функциям/данным всей системы одновременно. Например, оператор бюро про- пусков не должен иметь возможность выгрузить полный список сотрудников и посетителей со всеми их данными разом или скачать резерв- ную копию базы данных, а системный админи- стратор должен иметь доступ к административ- ным функциям – настройкам, управлению системными параметрами, журналам аудита, но не должен иметь доступа к персональным данным или функциям управления охранной сигнализацией. Система должна предоставлять пользователю только те возможности, которые нужны ему для выполнения непосредственных обязанностей: поиск сотрудника по ФИО, заве- дение нового пропуска или просмотр журнала системных событий. В противном случае при взломе или в силу человеческого фактора воз- можно от лица одного пользователя, например, "слить" все персональные данные из системы или создать нового "администратора" для последующего доступа злоумышленника к системе. Где же выход? Как же обеспечить юридически правильную, а главное, безопасную обработку персональных данных в системе безопасности? Простейший и самый доступный вариант – вообще не заниматься обработкой персональ- ных данных. В теории возможно выдавать сотрудникам и посетителям только обезличен- ные пропуска, вести в системе только учет номеров карт, не использовать биометриче- скую идентификацию. На практике же такой подход либо невозможен, либо неудобен. Тре- бования по безопасности диктуют необходи- мость осуществлять фотоидентификацию, выдавать разовые пропуска, фиксируя ФИО и номер документа, удостоверяющего личность, контролировать доступ по результатам распо- знавания лиц. Другая крайность – поместить всю систему безопасности в контур обработки персональ- ных данных: предоставить доступ к оборудо- ванию, серверам, рабочим местам только для сертифицированных специалистов в отдель- ных помещениях со строгими ограничениями по доступу. Наружу из этого контура будут "торчать" только считыватели и выходы управ- ления для управления замками и другими исполнительными устройствами. Основная сложность такого подхода в топологии: необходимо так расположить все сервера, рабочие места и органы управления, чтобы изолировать защищенную систему от осталь- ной части предприятия. Не удастся разместить охранника с АРМ за стойкой на входе в зда- ние, нельзя будет "просто зайти в службу без- опасности получить пропуск". Кроме того, работать с системой смогут только включен- ные в перечень специалисты, а значит, будут сложности с доступом обслуживающих орга- низаций, сменой охраны и другими кадровы- ми изменениями. Самый оптимальный вариант – выстроить такую архитектуру системы безопасности, при кото- рой обработка персональных данных осуществ- ляется, но только в корректно изолированном и защищенном сегменте системы. А те части системы, на которых обработка персональных данных запрещена, например которые не раз- мещены в соответствующих помещениях или не сертифицированы, этой обработкой и не зани- маются. Так, контроллеры и исполнительные устройства, управляющие доступом по предъ- явлению карт, сервера и АРМ управления про- пусками и правами доступа не хранят и не обрабатывают данные о владельцах пропусков и могут находиться вне защищенного сегмента, а сервера и АРМ выдачи пропусков сотрудни- кам и посетителям уже размещены в защищен- ном сегменте системы, и работают с такими АРМ уже выделенные специально обученные сотрудники. К сожалению, не все современные решения и программные средства поддерживают такую гибкость в работе с данными. Например, на всех рабочих местах есть доступ к списку вла- дельцев пропусков: нашел пропуск – увидел сведения о владельце. И другого не дано. Но даже там, где с прикладной точки зрения доступ к данным разграничен правами, техни- чески внешние АРМ продолжают осуществлять двусторонний сетевой обмен с центральным сервером, расположенном в сегменте обработ- ки персональных данных. А такой технической возможности быть формально не должно – это уязвимость. На вышеописанных примерах можно увидеть, что часть средств обеспечения безопасности по своей природе не готова/не пригодна к созда- нию решений с юридически корректной обра- боткой персональных данных. И для того, чтобы не изобретать велосипед и/или не тратить огромный бюджет на то, чтобы привести систе- му, построенную на таких средствах, в соответ- ствие с законом, лучше выбирать решения, исходно спроектированные с учетом требова- ний по обработке персональных данных. Аналогично и с кибербезопасностью. Продукт, реализованный на базе современных принци- пов обеспечения информационной безопасно- сти, взломать гораздо сложнее и, как следствие, дороже. Соответственно, выбор такого продук- та несет гораздо меньше рисков, нежели при- менение "дырявого от рождения" решения. А значительная часть продуктов на рынке, увы, является таковой, поскольку была спроектиро- вана/создана во времена, когда никто не думал о киберугрозах, "Интернет был по талонам" (карточкам) и "640 килобайт хватало всем", "необходимым условием работы является отключение антивируса". Конечно, частично защитить решения на таких продуктах возможно с применением наложен- ных средств: выделить систему безопасности в отдельную подсеть, закрыть все сетевое взаи- модействие корректно настроенными сетевыми экранами, рабочие места оснастить современ- ными средствами ИБ-мониторинга. Но нало- женные средства не панацея. Отдельные прин- ципы, заложенные в архитектуру системы без- опасности на этапе ее проектирования много лет назад, делают конечное решение исходно подверженным современным киберугрозам. К таким ошибочным принципам можно отнести ориентированность на работу в изолированном сегменте сети, отсутствие защиты протоколов коммуникации с оборудованием или работа в операционной системе только с администра- тивными правами. Только решение, исходно спроектированное с учетом актуальных требований по обработке персональных данных и кибербезопасности, позволит качественно обеспечить физическую безопасность и минимизировать экономиче- ские, юридические и репутационные риски взлома и утечки данных, которые сегодня как никогда высоки. Список литературы 1. https://www.infowatch.ru/company/presscen- ter/news/obyem-utechek-persdannykh-v-mire- vyros-vdvoye 2. https://www.infowatch.ru/analytics/analiti- ka/utechki-informatsii-v-mire-i-rossii-za-pervoye- polugodiye-dve-tysyachi-dvadtsat-chetvertogo-goda 3. https://www.garant.ru/news/1770029/ 4. https://www.secuteck.ru/news/sber-lichniye- danniye-pochti-90-vzroslogo-naseleniya-rossii- est-v-otkritom-dostupe n декабрь 2024 – январь 2025 www.secuteck.ru Ваше мнение и вопросы по статье направляйте на ss @groteck.ru Д ля защиты от утечек необходимо также обеспечить высокий уровень киберзащищенности решения – устойчивости системы к различным ата- кам и взломам.