Комментарии 37
Спасибо! Теперь действительно кажется, что любые коробочные решения похожи на черный ящик и их надо прям смотреть-смотреть.
аутсорс сейчас — это частый способ резать косты на разработку даже при всех сопряжённых с этим рисках информационной безопасности.
Аутсорс разработка в 1С (и прочем энтерпрайзе) всегда дороже, и соответственно, покупают его не для того, чтобы "резать косты". Если мы не о приходящем раз в месяц фрилансере "помочь закрыть месяц", а о более-менее серьезных задачах.
Извините, но и остальная статья на примерно таком же уровне владения вопросом.
Согласен, причем не просто дороже, а непредсказуемо дороже. Даже у очень крупных интеграторов уровень среднего непредсказуем, про культуру разработки вообще молчу.
В контексте больших проектов и крупных компаний я вполне согласен с вами - там действительно цель совсем не в урезании костов, а в ускорении сроков реализации проекта (в особенности, если своей необходимой экспертизы нет/мало, а растить ее долго).
Но не стоит тут забывать про формы сотрудничества типа ГПХ/СМЗ или небольших ИП - они вполне могут привлекаться для более мелких задач на вполне себе постоянной основе. Не говорю уже о тенденции последних лет, когда встречаются компании, которые как раз целенаправленно, с целью именно сокращения OPEX, переводят штатных разработчиков в на форму взаимоотношений по типу ГПХ/СМЗ/ИП (нет больничных/отпускных, других страховых отчислений от работодателя + техническое обеспечение такого "сотрудника" ложится также полностью на него самого). Все это в конечном итоге в реальности тоже ведь аутсорс, хоть и принимает такие странные формы.
Из опыта: стандартный отчёт -> сохранить в эксель -> отправить на почту. База активных клиентов у конкурентов.
DCOM, внешние обработки, подключения на левые адреса - это все, конечно тоже имеет смысл рассматривать, но в них ли угроза?.
Банально, с вырезанными внешними коммуникациями, сотрудник распечатал отчёт и вынес прям в бумаге.
Ну в общем: аутсорсеры, конечно, могут так постараться, что бы состряпать вам "ядовитую" платформу, но куда им до обычных пользователей.
на такие случаи разделение доступа к записям БД или по какой то аналитике или как в банках доступ только поштучно с логированием этого самого доступа.
У управляющего персонала, а его априори пока меньше, свои способы мотивации к соблюдения секретности и это прям настоящая дыра, но это, опять же, уже близко к уровню и рискам руководства.
А вот с обфускацией данных, т.е. к примеру для цифровых итоговых показателей в отчете совершенно не нужны реальные наименования 1000 ведущих клиентов, их можно заменить на Ивановых Петровых и Сидоровых - с такими решениями я не сталкивался.
...обфускацией данных...
А кстати да, хороший вопрос вы подняли. Если телефонные номера и почтовые адреса очень часто маскируются, то вот с остальным, действительно не очень.
Ну как бы если сотрудник может на рабочей машине "просто распечатать" конфединциальную инфу - ну ой, а не безопасность. Я работал в Каспере в момент раскола, и уже тогда инфовоч имел решение по контролю печати. Даже если тогда оно работало не очень, то спустя почти 20 лет появилось уже дофига решений. Ну и в целом DLP это про контроль рабочей станции, откуда есть доступ к грифованным/классифицированным документам. Так что сохранение в эксель ещё не означает покидание контура, и ключевой аспект нужен именно на этом. Чтобы ни через телеграм веб, ни через scp и прочее инфа не улетела с защищенного рабочего места.
Именно, дело не в 1С, а в общей культуре безопасности.
Пакетное решение DLP на 50 станций стоит в районе 1млн. Я вас уверяю, большинство собственников скажет - хрен с ней этой базой пользователей. Мне кажется тут многие живут в волшебном мире корпораций с огромными бюджетами, но нет, ПО за 1млн покупать мало кто готов в малом и даже среднем бизнесе.
все же 1 млн это даже не лада-гранта по нынешним временам, среднячек то мог бы себе позволить, если не в кредит?
А тут дьявол кроется в деталях - это стоимость только лицензий на 1 год или железа+внедрения+настройки+сопровождения+реагирования? Купить любой инструмент мало, надо уметь его внедрить в процессы, развивать и поддерживать потом. В случаях с малым и средним бизнесом, отпугивает не стоимость лицензий чаще, а то, какие накладные расходы это понесет за собой на дистанции.
Да и будем честны - DLP не панацея и любой из тех, кто плотно работал с этим классом продуктов, внедрял, решал проблемы и разгребал инциденты, писал исключения, может с уверенностью сказать, что обойти его не то чтобы невозможно. Само решение хорошее, но оно должно работать в комплексе с отстроенными процессами - классические подходы "всем все запретить" сейчас уже не пройдут.
В хоть сколько-нибудь серьёзном бизнесе база клиентов стоит гораздо дороже 1млн.
Забыли упомянуть про мобильное приложение 1С, которое может целиком крутиться на мобильном девайсе, включая базу данных, и не требует Интернет-подключения
У вас в Озоне для 1С настроены CI/CD и процесс тестирования, в чем смысл этой статьи?
Очевидно ozon большой, не везде есть ci cd и тестирование.
При таких размерах компании, если бы их не было, было бы очень и очень больно.
То, что описано в статье выше - собирательный образ основных узких мест, которые встречались при столкновении с продуктами 1С и процессами, построенными на них в разного размера и направленности бизнеса компаниях.
Смысл прост - представьте, что вы относительно новичок в ИБ, продукты 1С встречали тольк на слуху, пришли в новую компанию, а там вам говорят, что ценным активом для бизнеса являются продукты 1С и их хотелось бы проаудировать и привести в порядок.
Если грамотный человек захочет выгрузить какие-то данные из 1С - он это сделает. Всё остальное это стрельба в ногу обычным пользователям.
Так вопрос 100% надежности вроде и никогда не стоял. В конечном итоге можно зайти и через БД. Главное что бы стоимость сего мероприятия была неподъемна не самым подготовленным людям.
Я бы тут даже расширил тогда, так как этот постулат, в конечном итоге, легко масштабируется и на любую иную систему.
Самая безопасная эта та система, которая потушена, и к ней не имеют ни логического ни физического доступа никто, но само собой в реальности так нельзя сделать и вот тут уже и начинается борьба компромиссов удобства/работоспособности/безопасности.
А что мешает вести разработку в хранилище конфигурации, чтобы доступ у разработчиков был только к тестовым данным?
Я уж извиняюсь, но вы где-то в прошлом застряли.
Нет никаких сложностей в том, чтобы использовать различные стенды. И доступ к проду разработчикам не давать. А на тестовых стендах пусть делают что захотят
CI/CD, git в компаниях с развитой квалификацией используют. Напрямую разработчику лезть в конфигурацию не нужно, достаточно из Jenkins или girlab нажать кнопку и релизная ветка разольется на прод
В больших компаниях с развитой инфраструктурой и достаточными ресурсами, вполне соглашусь - там именно таким подходам и следуют. Хотя и так не без ложки дёгтя бывает - даже там не все и не везде умеют и готовы решать вопросы с наполнением тестовых стендов необходимыми для их корректной работы данными.
Ограничивать разработчиков в доступах на прод вполне логичный шаг и с этим массово в последние года все меньше проблем становится, но вот процессы создания тестовых стендов крайне желательно тщательно изучать. Обычно существуют довольно хорошо реализованные на стороне инфраструктуры мониторинги и контроли на доступы из тестовых сегментов в прод, но вот об обратном взаимодействии все ещё мало кто сходу задумывается.
Слияние всех описанных выше факторов может порождать, в какой-то момент, "интересные" открытия вида - тестовый стенд = реплика с прода 1-7-14-30 дневной давности. И хорошо ещё, если это по итогу быстро можно обнаружить в рамках каких-либо автоматизированных проверок тестовых сред, а не всплывает как-нибудь невзначай, либо вообще на инциденте.
Строго говоря:
Конфигурация (.cf) - это метаданные плюс код;
Информационная база - конфигурация ( точнее, конфигурации - их несколько) плюс данные.
Как опытный пользователь 1С, я с интересом читаю подобные статьи, чтобы глубже вникнуть в особенности систем. Есть желание перейти в администрирование и сопровождение. Однако после трёх ошибок в самом начале статьи остальное идёт через силу. Может быть, у вас есть знакомые редакторы или копирайтеры? Если нет, то рассмотрите найм кого-то на вычитку и коррекцию.
Мнение об "1С и безопасности" одной строкой: если речь не идёт о перс.данных и зарплате, все ваши очень важные цифры "из 1С" в 95% случаев никому нафик не сдались кроме вас самих.
К сожалению, как раз в более чем 95% случаях продукты 1С используются по прямому назначению и содержат все те самые выплаты/зарплаты и разнообразные ПДн сотрудников, клиентов, контрагентом.
Ха, циферки. В 1С, например, могут храниться сертификаты для доступа к банк-клиенту.
Токен в 1Се хранить? В присоединенных файлах чтоли?) Ну тут как говорится Press F вашей компании
В безопасном хранилище. Но если злоумышленник получит доступ к базе под пользователем, у которого есть права на использование токена (или вовсе под полными правами), он сможет провести банковские операции.
Если серьезно, то такие вещи надо хранить вовне 1С, например Vault. https://infostart.ru/1c/articles/2100731/
С другой стороны даже внешние секреты надо админить, и от нечистоплотных админов уже не защитит ничего.
А "безопасное хранилище" БСПшное - это фикция, безопасного в нем мало.
Взгляд на 1С глазами безопасника