Практический опыт построения защищенного контура для 1С-приложения

Мой доклад будет из практическо-клиентской и немного философской плоскости. В нем будет не так много про технические способы организации взлома и защиты 1С-приложений, он будет больше о том, что нужно сделать, чтобы заполучить крупного клиента с высокими требованиями к информационной безопасности, и как его эффективно обслуживать, чтобы инфобезопасники были довольны.

Безопасность – это риски, которые нужно оценивать в деньгах

Начну я с картинки про «Кровавый Ынтырпрайз».

Если у вас маленькая организация, где нет высоких требований к безопасности, и, если ваши меры информационной безопасности не окупятся с точки зрения выгоды для бизнеса – не надо с этим чересчур заморачиваться, особенно в плане 1С.

В своей практике я встречал много перегибов в сторону «большой безопасности» – это и парольная политика в 1С по 16 символов, и регулярная смена паролей, и блокировка учеток – чего только не встречалось. А на практике большая часть взломов обеспечивается средствами социального инжиниринга.

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

Каждый раз, когда вы хотите сделать что-то крутое и очень безопасное – нужно пропустить это через сферу финансовых рисков бизнеса. С этого начинается стандарт безопасности, о котором я буду говорить дальше.

Потому что, когда вам бизнесмен говорит: «Почему у нас такая дыра? Давайте займемся безопасностью, проведем тест», вам в первую очередь нужно разобраться – сколько бизнес готов заплатить, и сколько компания потеряет в случае, если данные утекут.

Бизнесмен должен понимать, во сколько ему обойдется утечка тех или иных данных, потому что только тогда он может здраво рассуждать на тему, какие меры безопасности ему стоит предпринимать. Если утечка данных приведет к потерям в 10 тысяч рублей, внедрять для этого DLP-систему за 10 миллионов – бессмысленно. Если бизнес это понимает, все сразу встает на свои места – ваша жизнь становится проще, и вы не занимаетесь тем, чем не нужно заниматься.

Лично я считаю, что безопасность – это всегда накладные расходы, которые не несут прямой пользы бизнесу. Это некая защита от рисков, а защищаться от рисков нужно, оценивая их в финансовом плане.

Поэтому первый слайд – он скорее не про безопасность, он про небезопасность.

Следующий слайд – про философию.

В свое время я был большим фанатом Кевина Митника – это известный хакер, он взломал кучу систем, включая компьютеры ведущих специалистов по безопасности ряда крупных компаний.

У Кевина Митника есть крутая книжка «Искусство обмана» – рекомендую почитать, это классный труд. Причем, сама книжка посвящена взлому, но в ней нет практически ничего про технологии. Почему? Потому что самый простой вариант взлома – это именно социальная инженерия. Подарить коробку конфет секретарше намного проще, чем заниматься перебором паролей, брутфорсом, пытаться обойти файрвол или искать уязвимости.

В современном коммерческом хакинге, если вас хотят взломать осознанно для получения каких-то данных – наиболее эффективны именно методы социальной инженерии. Это – достоверная точка зрения, она зафиксирована в стандартах информационной безопасности, ее несомненно нужно иметь в виду.

В книжке Кевина Митника есть фраза:

Любой, кто думает, что системы ИБ обеспечивают реальную безопасность, создает иллюзию безопасности.

Даже если у вас на предприятии есть крутые DLP-системы, но нет процессов, которые поддерживают вашу безопасность, это значит, что у вас безопасности просто нет.

Поэтому, прежде всего, информационная безопасность – это не про то, какие у вас крутые файрволы, и как регулярно у вас устанавливаются патчи обновлений. Да, это важно и, несомненно, нужно.

Информационная безопасность – это про процессы:

• про парольную политику;

• про прием сотрудников на работу;

• инструктаж сотрудников;

• правильное увольнение;

• своевременное блокирование учеток;

• ограничение доступа людей с правами администратора;

• дублирование доступа прав администратора и т.д.

Большую часть работы придется проделать организационно.

Поэтому здесь я хочу рассказать про ISO 27001 – это, наверное, самый популярный стандарт информационной безопасности. Компания WiseAdvice одна из немногих в мире 1С сертификацию по этому стандарту прошла. Пройти такую сертификацию достаточно дорого, поэтому компаний, которые всерьез этим занимаются, не так много.

90% работы по этому стандарту заключается в приведении процессов компании в соответствие со специальными регламентами, разработанными с точки зрения информационной безопасности.

За каждым из документов, который перечислен в списке на слайде, стоят недели обсуждений, внедрений, инструктажей. Отдел информационной безопасности – это люди, которые по должности занимаются только этим. И менеджер по информационной безопасности – он, прежде всего, занимается обучением сотрудников, внедрением процедур. Он должен положить ключи к клиент-банку в сейф, обеспечить их выдачу только под роспись в журналах, которые были бумажными, а теперь стали электронными.

Забегая вперед, скажу, что DLP-системы у нас нет (не было на момент доклада). DLP-система еще в три раза дороже, но при этом пользы от этого достаточно мало.

Так вот, прежде чем вводить парольную политику, организовывать специальную базу для управления конфигурациями (CMDB – это процессная штука, здесь она тоже нужна), нужно привести в порядок все процессы внутри компании. Это большая работа.

Вы должны знать, какие права у ваших сотрудников, каким секретаршам можно подарить букет, чтобы получить доступ к банковской информации, и как проверить, что никто этим сейчас не занимается.

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

Во всей этой истории с CMDB и с ISO 27001 самый главный документ – «оценка угроз», в нем каждая угроза оценивается в деньгах, насколько она может привести к финансовым потерям.

Международный best practice говорит, в первую очередь, о процессах, и потом уже о технологиях. Грубо говоря, вы можете сколько угодно защищать ваши системы, но, если у вас в серверную может зайти охранник бизнес-центра по своему пропуску, разговор о безопасности на этом можно закончить.

Даже мы, когда всем этим занимались, выявили столько всего интересного, что 1С с ее текстовым файлом реестра кластера отошла на третий план.

Про организационную часть я уже сказал, необходимую часть философии, надеюсь, тоже донес – это правда нужно. Рассмотрим, какие есть технические меры – у нас все-таки техническая конференция, доклады про 1С.

Внешний и внутренний Penetration Test. Как проводить и зачем это делать

Начинать нужно, конечно, с Penetration Test.

В 1С есть некоторые уязвимости, о которых вы знаете – в 1С небезопасный реестр кластера, который в случае неправильных настроек безопасности сервера позволяет легко получить доступ к табличкам в СУБД напрямую. Эти уязвимости могут быть и в вашем конкретном кейсе эксплуатации систем 1С. Они могут быть инкапсулированы, они могут не выстрелить.

Чтобы обнаружить такие уязвимости, нужно сделать Penetration Test.

Кевин Митник писал: «Я попал в тюрьму за хакинг. Теперь меня нанимают делать то же самое, но легально и за деньги».

Penetration Test – это именно та история, когда хакеры легально за деньги пытаются взломать вашу систему.

Причем, одну конкретную систему и одну конкретную платформу в рамках информационной безопасности, конечно же, рассматривать нельзя. У вас может быть обеспечен полностью безопасный 1С-контур, при этом дырявый веб-сервер, из-за чего у вас к реестру кластера можно попасть через веб-сервер.

Тема сегодняшнего митапа – «Безопасность в 1С», но безопасность не бывает только в 1С. 1С живет в некой инфраструктуре, которая может быть либо безопасна, либо небезопасна. И, конечно, Penetration Test нужно делать с учетом всех элементов вашей инфраструктуры.

И, самое главное, что я хочу сказать про Penetration Test – его никогда нельзя проводить своими силами.

У каждого системного администратора, у каждого разработчика всегда будет ощущение, что его система идеальна. Поэтому разработчик никогда ничего сам тестировать не должен – для этого должен быть специальный человек, QA, который за него будет этим заниматься. Потому что очень тяжело тестировать свой код – кто пробовал, тот знает.

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

Для этого действительно нужно нанимать внешние компании. Я сам не сторонник привлечения подрядчиков, если внутри есть хорошие кадры. Но именно Penetration Test должен быть проведен с помощью внешнего подрядчика.

Если вы работаете на внешнем проекте, и ваш клиент большой и важный – он обязательно запросит с вас Penetration Test. Как минимум, его статистику.

И для целей внутреннего аудита, если это кому-то вдруг потребуется, тоже надо делать Penetration Test и тоже чьими-то чужими руками.

Penetration Test бывает внешний и внутренний.

• Внешний Penetration Test надо проводить обязательно, если вы хотите, чтобы у вас были клиенты из крупных организаций, про которые у меня был первый слайд, представители так называемого «Кровавого Энтерпрайза». Он именно поэтому и кровавый, что там есть так много всего нелогичного. В таких проектах это обязательно потребуется, у вас его точно попросят. Penetration Test – это должен быть некий отчет, где проверят всю вашу инфраструктуру на предмет возможности проникновения извне. Это очень важно – все, что у вас торчит извне, все должно быть закрыто железно. Почтовый сервер, роутер, файрвол, любые сервисы, включая сервисы 1С. Даже в небольших организациях, конечно, это стоит обновлять и закрывать. Если у вас что-то опубликовано вовне, это обязательно нужно включить в проверку на внешний Penetration Test.

• Но не стоит на этом останавливаться, вторая история, с которой будут разбираться более детально – это внутренний Penetration Test. Он делается не ради попытки что-то сломать, а чтобы исключить наличие излишних прав у пользователей. Например, у человека должны быть права только на свою систему, он не должен заходить в соседнюю систему под администратором. Чтобы такие ситуации выявить и исключить, проводят внутренний Penetration Test. Здесь уже с приглашенными сотрудниками несколько сложнее, здесь можно просто позвать коллег из соседнего подразделения. Поскольку мы представляем группу компаний, мы можем привлекать для внутреннего тестирования специалистов из соседней компании. Но в вашем кейсе этих «белых хакеров» придется звать к вам в офис и просить проделывать внутренний Pentest. Более того, внутренний Pentest должен быть достаточно регулярным. Если извне у вас обычно ничего особо не меняется – внешний Pentest вы можете проводить раз в квартал, этого достаточно. То внутри у вас все меняется достаточно регулярно, особенно если CMDB недостаточно хорошо выстроена. Поэтому nmap или любой другой сканер портов с возможностью строить отчеты и видеть, что появился какой-то новый порт, нужно запускать регулярно.

Внешний Pentest стоит недорого, ценники начинаются от 30 тыс. рублей – его проводят отдельные ребята со специальной подготовкой, самим провести Pentest для крупной компании достаточно проблематично.

С внутренним Pentest немного сложнее. Он занимает больше времени и в отдельных случаях может проводиться другими подразделениями внутри организации – одни подразделения готовят инфраструктуру, другие – проводят Pentest.

Кажется, что внутренний Pentest нужен только вам.

Но на самом деле более-менее крупные организации и банки у нас запрашивают внутренние Pentest на регулярной основе для подтверждения неизменности нашей инфраструктуры.

И еще внутренние Pentest запрашивают те, у кого есть высокие требования к хранению персональных данных – если вы, не дай Бог, храните персональные данные какой-нибудь крупной компании.

И если вы оказываете какие-то услуги, то, чтобы нормально выполнить требования 152-ФЗ, вам внутренний Pentest тоже нужен.

Сначала кажется, что все это лишнее, но потом набирается много аргументов за внутренний Pentest. Потому что желательно представлять, какие у вас на каждом сервере открытые порты, и что вы с ними можете делать.

Все, что я рассказываю про требования клиента – это практический опыт WiseAdvice. Это то, через что мы проходим, когда к нам заходит внешний крупный клиент, который хочет использовать наши сервисы.

Мы должны удовлетворить все требования, которые отдел информационной безопасности клиента предъявляет к нашим сервисам.

Это типичный кейс для многих 1С-франчайзи и других компаний, которые оказывают услуги. Если ваш исполнитель – франчайзи, и вы к нему обратитесь, вам тоже должны будут предоставить отчет об аудите, отчет о Pentest. По крайней мере, если вы к нам обратитесь.

Открытые порты и Pull вместо Push – как организовать взаимодействие с незащищенным контуром

Открытый порт – это боль. Чем больше открытых портов у ваших сервисов, тем больше шансов придраться к вашей информационной безопасности.

Как проходит ИБ-аудит в большинстве кейсов?

• Приходят люди, запускают nmap и смотрят, какие порты открыты.

• Потом просят объяснить, какие сервисы находятся на этих портах.

• И по каждому из этих сервисов требуют предоставить Pentest, показать регламент обновления сервиса, перечислить пользователей, имеющих права администратора.

Грубо говоря, если у вас в контуре, который должен быть защищенным для клиента, появился открытый порт, у вас появилось плюс 10 дополнительных бумажек или процедур.

Клиентов чаще всего интересует та часть инфраструктуры, в которой будут храниться их данные. Если в этой части какой-то сервис открыт для внешнего воздействия и с ним можно что-то делать, к нему будут большие требования.

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

И если вы именно в этом контуре делаете новый сервис, который открывает какой-то новый порт вовне – это будет вызывать кучу вопросов. И чем больше таких портов, тем хуже.

Поэтому желательно изначально планировать все взаимодействия между сервисами только внутри этого контура.

Но что делать, если нужно получать информацию извне? На слайде показана картинка из какого-то IAAS-сервиса – суть в том, что есть методика Push и есть методика Pull.

• Push – это когда вы открыли порт, и вам туда кто-то закидывает данные. Допустим, у вас работает socket к SQL-серверу, и туда кто-то что-то пишет. Вот это – Push, и это плохо, по аналогии как многие не любят, когда на телефон приходят push-уведомления.

• Pull – это история, когда не к вам обращаются, а вы обращаетесь.

Приведу пример: вы можете опубликовать в 1С HTTP-сервис и дать возможность стороннему сервису к вам обращаться. Либо вы можете каждую минуту из вашей 1С по HTTP обращаться к другому сервису.

В случае, если у вас будут требования к безопасности, – только второй вариант. Опубликованный HTTP-сервис – это очень большой пласт вопросов, и это Push.

Лучше всего использовать обращение к защищенному HTTPS через

Новый HTTPСоединение(...,ssl)

Через этот вызов вы можете регулярно в фоне с определенным интервалом обращаться к другому сервису – это единственная возможность удовлетворять требованиям безопасности.

Двухфакторная авторизация в 1С приложениях

Дальше – двухфакторная авторизация.

В 1С двухфакторная авторизация есть. И при организации защищенного контура сделать второй фактор авторизации средствами 1С несколько проще, чем приобретать для этого отдельное ПО или интегрироваться с внешними сервисами. Как минимум в нашем реальном кейсе это оказалось проще.

Хотя в 1С тоже не все так хорошо, потому что в 1С двухфакторную авторизацию придется написать кодом – эти три строчки приведены на ИТС.

Суть двухфакторной аутентификации в 1С можно свести к одному – платформа генерирует некоторую служебную переменную secret, которую вы дальше средствами встроенного языка посылаете туда, куда хочется. У клиента вылезет это окошко, куда он должен будет этот «секрет» ввести. Достаточно простой механизм.

Но процесс отправки этого «секрета» через SMS, e-mail и т.д. – вам придется описать в коде самостоятельно.

Самый простой и проверенный способ – это именно SMS, потому что не все крупные заказчики хорошо относятся к мессенджерам и к e-mail, есть разные политики. Но SMS в 95% случаев прокатит, и лучше рассчитывать именно на SMS. Современные SMS-сервисы работают хорошо – вам нужно будет только зарегистрироваться, получить API-key. А потом в коде сделать HTTP-запрос на определенный адрес с вашим API-key. Этого достаточно, чтобы отправить SMS. Я рекомендую этот способ.

Single sign-on – единая авторизация в 1С приложениях

Скорее всего, любой крупный заказчик у вас попросит возможность единой авторизации через Single sign-on, потому что рабочее место сотрудника в крупной компании выглядит примерно так, как на слайде.

Это скрин с Okta, но может использоваться и OneLogin либо еще какой-то другой сервис, в котором собираются облачные сервисы. Для этих облачных сервисов есть некий единый Single sign-on-провайдер. В России еще не везде так, но западные ребята практически все к этому уже пришли.

В крупной компании, когда ты заходишь на компьютер под своей единой учеткой, ты можешь залогиниться и в AWS, и в ADP (аналог Бухгалтерии), и в WorkDay (сервис для расчета зарплаты). Соответственно, любой нормальный заказчик захочет сюда по кнопке Add app добавить еще одно приложение, чтобы увидеть здесь еще и 1С. И с большой долей вероятности к вам прилетят требования по Single sign-on.

Но здесь все непросто, потому что единственный предусмотренный вариант организации Single sign-on в 1С – это опубликовать базу на веб-сервере и работать с ней через веб-клиент. Но так делать небезопасно – я чуть позже расскажу, почему.

В 1С предусмотрен вариант работы с Single sign-on через OpenID Connect. Его можно использовать, это позволяет организовать единую авторизацию – заказчику можно об этом сказать.

Но пока что с OpenID Connect много проблем. Например, у меня получилось авторизоваться в 1С только через учетку Google. Через ADFS (провайдер от Microsoft) – я в 2020 году попробовал, у меня авторизоваться не получилось, хотя в Okta приложения работают именно через ADFS.

Поскольку OpenID Connect пока что работает нестабильно и только для работы через веб-клиент, я бы не рекомендовал связываться.

Если подводить итог: в 1С можно правильно сделать двухфакторную авторизацию – это нужно и удобно. Но OpenID Connect в качестве авторизации через Single sign-on лучше заменить какими-то сторонними средствами.

Веб-клиент 1С не поддерживает требования OWASP. Поэтому только изолированный контур

А теперь – самое интересное, что я хотел сказать в своем докладе.

Использовать 1С как Internet Facing Application небезопасно, и в текущем виде это никогда ни при каких условиях не может стать безопасным, потому что доработать веб-клиент вы не сможете.

У любого серьезного заказчика к вашему решению будет требование на соответствие стандартам OWASP по обеспечению безопасности в веб-приложениях.

Большинство облачных приложений эти требования поддерживают. Веб-клиент 1С требования стандартов OWASP не поддерживает.

Более того, в соответствии с публичными Pentest веб-клиент 1С однозначно уязвим. Что бы вы там ни делали внутри средствами кластера – уязвимость у вас в любом случае будет, крупный заказчик в любом случае систему не примет.

Поэтому, когда вам в кейсе нужен нормальный защищенный контур, чтобы у вас заказчик был спокоен и вы сами как крупная организация были спокойны – используйте доступ через RDP.

• RemoteApp при использовании RDP с внедренным AD FS сейчас уже обеспечивает Single sign-on.

• Если мы RDP используем как RemoteApp, у вас по ссылке сразу запускается тонкий клиент 1С в изолированном контуре – все это от вас инкапсулируется, и вы обеспечиваете безопасный запуск нормального тонкого клиента 1С для крупных заказчиков. Так делать можно, это работает, это хорошая практика.

• Организовать нормальную комфортную работу с 1С можно только через тонкий клиент, а поставить в контур крупной компании неизолированное исполняемое приложение тонкого клиента – почти без вариантов, вряд ли кому удавалось.

Что еще нужно знать про защищенный контур? Что там еще должно быть? С чем вам придется столкнуться, если вам эта история тоже будет грозить?

• Доступ к этому контуру должен быть через VPN – и HTTPS, и RDP только через зашифрованный канал. При этом защита VPN не в полной мере соответствует принятым сейчас в мире стандартам безопасности, поэтому вам все равно придется регулярно бороться с уязвимостями.

• Дальше – бэкапы. Самое интересное, что, говоря о безопасности, люди обычно забывают, что бэкапы тоже должны быть безопасными. Бэкапы тоже должны быть в изолированном контуре. Нельзя делать общий сервер бэкапов. Нельзя перемещать бэкапы между дата-центрами и т.д.

• Более того, бэкапы тоже нужно зашифровать – это тоже данные клиента, о которых он обязан заботиться.

• Более того, могут попросить зашифровать еще и сам физический сервер. Так бывает не всегда, но тем не менее, к этому тоже нужно было готовым.

• Соответственно, весь контур придется проверить на стандарты шифрования – там однозначно должно быть 256 битов.

Z версия платформы

Еще маленькие плюшки, которые можно подсказать на тему практического обеспечения безопасности – очень хорошо помогает Z-версия платформы. С ее помощью можно очень быстро отбиться от безопасников в госорганах, потому что часть работы за нас уже проделали. Две бумажки – сертификат ФСТЭК и ISO 27001 – закрывают очень много вопросов, жизнь становится более простой и приятной.

DLP система

Дальше – DLP-система. В нашем кейсе ее нет. По крайней мере, полноценной.

Конечно, в качестве DLP-системы можно рассматривать продукт «Лаборатории Касперского» InfoWatch Traffic Monitor. Но настоящая DLP-система для обеспечения реальной безопасности в крупной организации покрывает гораздо больше сценариев – мониторит практически все. И что было напечатано, и что было отправлено по почте, и что появлялось на экране.

Но если все-таки озаботиться и проинвестировать во внедрение DLP-системы, можно будет чуть-чуть снизить требования к изолированному контуру относительно того, что открытый порт – это боль. Конечно, боль останется, но она будет уже не такой сильной. Вы сможете уже говорить, что эту боль прикрывает DLP-система. Из 30 листов анкет инфобезопасников DLP-система будет закрывать 40% вопросов.

Вопросы

Является ли Pentest аргументом в суде?

Нет, у Pentest нет специальной формы, это не регламентированный документ. Просто если Pentest проводит крупная компания, это снизит объем вопросов по инфобезопасности от ваших клиентов из разряда Enterprise.

Конкретной методики проведения Pentest я не знаю – эта методика есть у белых хакеров. Pentest должен включать подробный отчет. Если вам предоставили отчет меньше, чем на 3 листа, вас обманули.

Pentest должен включать все сканы портов, все ваши Internet Facing Application, все текущие версии. Там должна быть информация о том, что у вас нашли извне. И там должны быть еще какие-то рекомендации о том, как обезопасить те или иные сервисы – обновить, изолировать или отказаться от них.

В нашем случае после Pentest веб-клиента нам просто написали рекомендацию отказаться от данного приложения в плане рассмотрения его как Internet Facing Application. Они нашли 17 различных способов взломать веб-клиент без перебора паролей, через уязвимость внутренней безопасности. В результате написали рекомендацию, что доступ к нему лучше закрыть.

Что должна предоставить фирма-франчайзи клиенту, чтобы он мог убедиться, что у них все в порядке с безопасностью?

Те анкеты, которые приходят к нам от крупных заказчиков, сочиняют отдельные подразделения, там практически исследования на все-все-все. Это – внутренний документ конкретного заказчика. Если у вас появится менеджер по информационной безопасности, то первая бумажка, которую он вам напишет, это будет политика безопасности, потом стандарт ISO 27001, а потом – вот эти требования к сторонним сервисам и к внешним подрядчикам.

Где можно посмотреть материалы по небезопасности веб-клиента?

В открытом доступе таких материалов я не видел. Но общими словами – внутри веб-клиента можно на JavaScript выполнить любой код, можно сделать injection.

От вас безопасники требовали бэкапы 3+2+1?

Нет, такие бэкапы – это скорее про Disaster Recovery. Естественно, резервное копирование должно быть, у нас есть резервный ЦОД. Но в нашем кейсе по Disaster Recovery не сильно докапывались, потому что у нас в основном в контуре используются базы Бухгалтерии и Заплаты, там интенсивность данных низкая, в требованиях – трое суток простоя. Это не так страшно. Поэтому безопасников Disaster Recovery не так сильно интересовало. Может быть, в каких-то кейсах это важно, но в наших кейсах Disaster Recovery безопасников не интересовал. Информационная безопасность больше про процессы, про то, как мы защищаем данные клиента от того, чтобы их никто не похитил.

Не хотелось бы, чтобы меня обманул хакер, которого я сам позвал и деньги ему заплатил. Есть ли какие-то проверенные конторы?

Мы выбирали компанию для Pentest по принципу экономии затрат – нас не обманули. Pentest можно и за полмиллиона заказать, сделают то же самое, просто будет красивее бумажка, которую вы получите для этих целей.

Вы зря боитесь внешних тестеров. Чаще всего, внешний Pentest покажет, что у вас все хорошо. Сейчас даже обычные компании, у которых даже не все хорошо с информационной безопасностью, уже выучили, что такое файрвол. И порты чаще всего закрываются.

Что касается паролей, то тестеры их брутфорс не делают, никто не будет вам 10 суток перебирать пароли, если вы за это сами не заплатите. Они сделают простой брутфорс по словарю. Если у вас есть пароль из словаря, они вам это расскажут – вы пароль смените.

Почему Push – это плохо?

Если вам нужно интегрироваться с какой-то внешней системой, вы понимаете, что у вас есть база ЗУП и есть какой-то веб-сайт, и вам нужно из этого веб-сайта получать какие-то данные. У вас есть два варианта: первый – это опубликовать веб-сервис на стороне базы 1С, и второй – опрашивать веб-сайт по фоновому заданию.

Как нормальный человек в классическом примере вы, конечно же, выберете опубликовать сервис на стороне 1С, и пусть вам эти данные присылают тогда, когда они появляются. Но в кейсе инфобезопасности HTTP-сервис – это открытый порт, куда вам извне могут что-то закинуть. И дальше с вас попросят Pentest – что будет, если в этот HTTP-сервис передать гигабайт информации, что будет, если в вашем HTTP-сервисе провести брутфорс паролей и т.п. Всю эту историю придется проходить.

А если у вас HTTP-соединение, которое обращается к внешнему сервису – вы просто говорите, что у вас есть внешний сервис, к которому вы обращаетесь – вам никто не запрещает затягивать документы с сервера Документооборота. Чаще всего, с точки зрения инфобезопасности это проходит очень хорошо. Поэтому я и говорю, что, если вам нужен защищенный контур, используйте Pull.

Я работаю в оптовой компании, и мы тоже прошли два аудита безопасности – внутренний аудит KPMG и внешний аудит процессов. Мне как руководителю ИТ-отдела отчет по результатам аудита KPMG оказался очень полезен – там проверяли порты, сервисы на портах и прочее. В этом отчете сразу видны все косяки в инфраструктуре. Поэтому я считаю, что аудит – это классно, не нужно его бояться.

Да, такой отчет аналогичен тому, который предоставляют в рамках Pentest. А у инфобезопасников крупных клиентов мы проходим именно аудит процессов. От них прилетает анкета с 50 вопросами: начиная от того, как вы принимаете сотрудников на работу в компанию, и заканчивая тем, какими алгоритмами у вас шифруются данные при передаче от 1С к SQL-серверу.

Вы призываете не выставлять наружу веб-клиент, поскольку это не соответствует стандартам безопасности OWASP?

Не только потому, что это не соответствует стандарту OWASP, а потому что это в принципе небезопасно.

Как вы тогда выносите у себя личные кабинеты в веб?

В нашем кейсе есть отдельный личный кабинет – веб-страничка. В нем практически отсутствует бэкенд. Бэкенд личного кабинета заключается в том, что эта страничка складывает те самые JSON в определенные папки на сервере – даже с СУБД не заморачивались, потому что в браузере есть только фронт. А дальше 1С к этим JSON-файлам обращается, и все эти данные у себя берет. Если нужно организовать работу простых людей, то это все дело работает вот так.

К этому стороннему веб-приложению нет особых требований. Если же хотят иметь доступ для полноценной работы в 1С – это RDP. В любом случае, даже если к нам пришел крупный Enterprise, мы выкинули веб-клиент. Если люди пришли туда реально работать, то в веб-клиенте им работать будет неудобно. Тонкий клиент мы, скорее всего, не поставим в контур заказчика. Соответственно, вариант с RDP остается практически единственным, ну или вайтлистинг в конце концов. Просто потому, что при первом кейсе мы на то, чтобы дойти до данной схемы, потратили очень много времени. Мы пентестили веб-клиент, думали, как закрыть его уязвимости, чтобы остаться на едином неизолированном контуре. В итоге все-таки пришли к такой схеме. По итогам 3-4 аудитов считаю, что это практически единственно возможное с точки зрения безопасности решение.

Почему заказчик не может поставить тонкого клиента?

Если ваш заказчик – банк, то чтобы в банке что-то поставить, вам нужно пройти еще один аудит информационной безопасности, включая предоставление исходного кода того приложения, которое вы хотите поставить. Соответственно, есть стандарты разработки desktop-приложений, которым ваше решение должно соответствовать. Вы должны как-то убедить безопасников, что данное приложение никуда кроме вашего сервиса не обращается, а это очень непросто, потому что у вас нет исходного кода платформы 1С. Соответственно, с 90% вероятностью стандартный отдел безопасности крупного Enterprise вам завернет установку дополнительного ПО, которое не OpenSource и не имеет аккредитации среди западных вендоров.

Либо скажут, что можно использовать в «песочнице» – тогда VDI-сервер будет сделан на стороне банка, и вы за размещение базы на своих серверах денег не получите. Либо инфраструктура у вас должна быть в RDP.

Что такое VDI-сервер?

VDI – это Virtual Desktop Infrastructure, когда на уровне VMWare или другой виртуализации создается персональная машинка для работы. Не все на одном сервере работают, а на каждого сотрудника выделяется персональная  виртуальная машинка. В целом удобно, просто дороже в развертывании – многие Enterprise-компании, включая Газпром, так работают.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Безопасность в 1С".