HTTP сервис – друг или враг?

В 2018 году я выложил на Инфостарте цикл статей «HTTP-сервисы: Путь к своему сервису».

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

• Во второй части я показывал, как работать с oData. Получал данные по oData и передавал в самописный HTTP-сервис, и там на основании СКД формировался ответ, который возвращался в формате JSON.

• В третьей части я показал пример обращения ко всем возможным методам, и как работать с длительными операциями.

• В четвертой части показал, как работать с порциями.

А сейчас хочу вернуться к вопросу безопасности – расскажу, как застраховаться от внешнего воздействия через HTTP-сервисы.

Варианты применения HTTP-сервисов

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

HTTP-сервисы могут использоваться:

• для обмена данными между информационными системами;

• для обмена данными с какими-то мобильными устройствами – в конце выступления покажу пример, как можно использовать HTTP-сервис для обмена данными с мобильным приложением;

• для обмена данными с сайтами и порталами;

• с помощью HTTP-сервиса вы можете создать свой API, чтобы клиент мог работать с вашей информационной системой.

Все это может использовать HTTP-сервисы.

Все HTTP-сервисы работают по принципу «Запрос – Ответ»:

• Клиент формирует запрос к веб-серверу.

• Дальше запрос проходит какие-то проверки – проверяются заголовки, параметры, тело запроса (если сервис использует тело запроса).

• Если все проверки пройдены, то выполняется некий метод в вашей конфигурации и формируется ответ с кодом состояния:

  • обычно, если все нормально отработало, код состояния равен 200;

  • если что-то пошло не так, код состояния может отличаться;

  • есть методики, когда используется JSON RPC – в этом случае код состояния всегда равен 200, а в теле запроса в определенной структуре JSON содержится ответ, где в параметре error пишется, какие были ошибки.

Как обеспечить безопасность HTTP-сервиса?

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

Настройте регулярное создание бэкапов

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

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

Разберитесь, зачем вам HTTP-сервис и как вы его будете использовать

Когда я создаю новый HTTP-сервис, я отвечаю на три вопроса:

• Для чего нужен сервис?

• Кто конечный потребитель?

• Будет ли сервис выставлен наружу?

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

GET для безопасных действий, POST для небезопасных

Дальше нужно определиться с тем, по каким методам будет работать ваш сервис – будет ли он использовать только GET или POST, или он будет использовать смешанные методы.

• GET вызывает так называемые безопасные действия – он получает параметры и отдает некие данные из информационной базы.

• POST предназначен для более опасных действий – если вы хотите передавать логин-пароль, то GET для этих случаев не подойдет, лучше передавать в теле POST.

Зачастую получается, что программист научился создавать HTTP-сервисы, но изучил только то, как создавать GET. И он начинает через GET удалять данные, менять информацию и т.д. Такие вещи очень опасны.

Чтобы определиться, какой метод вам больше подходит, есть картинка, которая очень наглядно помогает выбрать тот или иной метод.

Повторюсь, что основные минусы GET по сравнению с POST – это то, что запрос можно кешировать, запросы могут оставаться в истории браузера, параметры передаются в URL, и GET не предназначен для передачи больших объемов данных.

Используйте HTTPS

Все, как мантру твердят: «Используйте HTTPS!» Я тоже буду твердить: «Используйте HTTPS!»

Смысл в том, что HTTP передает данные в открытом виде, соответственно, злоумышленник может вклиниться, получить ваши данные и подменить их.

Если вы смотрели мультик «Простоквашино», то там наглядно была показана MITM-атака (Man in the middle – атака человека посередине). Печкин принес посылку – это как раз был HTTP-запрос, в посылке было ружье, и банда хакеров во главе с дядей Федором эту посылку поменяла на другую.

Это – наглядный пример MITM-атаки.

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

Let’s Encrypt – лучше, чем самоподписанный сертификат, но есть минусы

Чтобы организовать HTTPS, нужны SSL/TLS сертификаты.

Часто встречается, что приходишь в какую-то крупную организацию, и там используют самоподписанные сертификаты. Если сервисы используются для внутренних целей, этого достаточно. Но если вы собираетесь выставить сервис наружу для обновления какого-то мобильного приложения, такой самоподписанный сертификат не подойдет. Лучше использовать бесплатный сервис Let’s Encrypt.

Но у сервиса Let’s Encrypt есть минусы по сравнению с платными сервисами:

• Нет гарантии, что с Let’s Encrypt не случится то же самое, что случилось со Startcom и Wosign. 5 лет назад был случай, что крупные производители браузеров перестали им доверять – эти сертификаты потеряли доверие.

• Еще нет гарантии сертификата. Например, если клиент зайдет на сайт, который подтвержден сертификатом платного центра, и потеряет деньги в результате фишинга, то эти платные центры обязуются выплатить некую сумму (от 10 тысяч долларов до 1.5 миллионов долларов).

• И основной минус – у Let’s Encrypt сертификаты выдаются на 3 месяца. С другой стороны, есть готовые скрипты, готовые боты, которые продлевают сертификат. Для Apache – это certbot, а для IIS – это win-acme.

Разделите сервисы

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

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

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

Опубликуйте сервис и настройте на него права

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

Плюс вам нужно продумать, как лучше организовать аутентификацию на этом HTTP-сервисе.

• Если аутентификация будет у самих сотрудников, вы можете им дать права на этот HTTP-сервис – тогда можно будет использовать даже RLS.

• Если вы будете использовать HTTP-сервис под единой учетной записью – тогда вам нужно в этой учетке все отдельно настроить.

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

Используйте VPN

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

Организуйте промежуточное звено

Есть варианты с промежуточным сервисом:

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

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

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

То же самое можно делать и другими средствами:

• можно установить файрвол, который ограничивает доступ, делает фильтрацию IP, закрывает порты;

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

Это тоже рабочий вариант.

Пройдите аудит ИБ

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

Какие-то фирмы проводят аудит раз в полгода, кто-то – раз в год. Какие-то фирмы начинают проводить аудит только тогда, когда с ними что-то случается.

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

Проводите постоянный мониторинг

Нужно производить постоянный мониторинг системы. Даже если у вас все работает, следовать правилу «Работает – не трожь» не совсем правильно. Система работает до тех пор, пока вы ее обслуживаете. Соответственно, можно настроить какие-то сборы метрик, можно проверять логирование. В 2019 году на Инфостарте был очень хороший доклад «Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей». Докладчик рассказывал о том, как у них некая нейронная сеть отлавливает некие изменения в системе и на основании этих изменений делает какие-то действия, сообщает о каких-то ошибках.

Если пойти этим же путем, анализировать все эти метрики, логи, то в принципе тоже можно сделать такого автоадминистратора, который все эти вещи будет сам отлавливать. Я думаю, что даже в каких-то крупных ИТ-гигантах такие вещи уже сделаны и успешно работают.

Храните логи в недоступном от злоумышленников месте

О чем еще важно помнить? Допустим, у вас есть логи, которые вы храните не очень защищенно. Логи тоже могут иметь некую конфиденциальную информацию.

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

Относитесь к паролям бережно

Еще раз напомню, что к паролям нужно относиться бережно. В практике моей компании был один случай: до 2018 года у нас администратора не было, состояние системы было подзаброшено, и мы наняли очень хорошего администратора, чтобы он все настроил. А потом директор решил проверить, действительно ли теперь все так хорошо, и обратился к моему коллеге, попросил его за хорошее вознаграждение взломать систему. У меня коллега далеко не хакер, он просто 1С-программист, который знал, что в компании есть некая база, которая опубликована наружу. Он открыл эту базу через браузер, быстро подобрал пароль к учетке пользователя-администратора с правом открытия внешних обработок, вошел в базу, открыл в ней обработку и сделал принтскрины, доказывающие, что у него полный доступ ко всем данным. Пароль был 123.

Как перечеркнуть все усилия по обеспечению безопасности

В феврале этого года я выложил статью «Выполнятор – как я породил монстра и лишился сна!». Это случай из 2017-го года. Я тоже человек грешный, я реализовал некое очень страшное решение через метод «Выполнить()».

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

Если я вижу такую статью, я пытаюсь пообщаться с автором и объяснить, почему так делать не стоит – об этом я расскажу дальше.

Все эти «Выполняторы» работают по одному принципу с небольшими отличиями:

• кто-то передает текст команды,

• кто-то передает текст команды и параметры,

• кто-то передает текст запроса и параметры;

• кто-то передает просто текст запроса.

Дальше это все попадает в некий метод «Выполнить()», где все это выполняется. Это некий троянский конь, через который с вашей системой можно что угодно сделать, вплоть до очистки всех данных.

Есть статья на ИТС «Ограничения на использование Выполнить и Вычислить на сервере». Если вы решили сделать универсальное решение, то ознакомьтесь с этой статьей, все вопросы уйдут.

Когда я общался с авторами, я интересовался, почему они сделали такое решение:

• Некоторые, как и я, хотели выйти из конфигуратора – статья про «Выполнятор» как раз показывает, что так делать неправильно.

• Кто-то говорил, что ему не нравится писать код в двух местах – в конфигурации-источнике и конфигурации-приемнике.

• Но чаще всего такие «Выполняторы» используют для ускорения процесса разработки, хотя это не совсем правильно.
  Представьте, что у вас есть некая база-источник, в которой вы делаете этот «Выполнятор», и у вас есть 10 баз-приемников, в каждой из которых по 10 методов. И вы каждый раз гоняете этот код.
  В один прекрасный момент базу-источник обновили, и ваши методы в других базах, возможно, перестали функционировать. В скольких местах вам придется править код? Как вы будете это отлавливать? Будете править в каждой базе?
  Если ваша фирма не собирается расти, то, конечно, вам придется поправить код только в 10 базах, но если количество баз за то время, пока вы все это настроили, выросло, это уже будет не ускорение, а замедление разработки.

Основные минусы «Выполняторов»:

• Практически невозможно отловить неоптимальный код. В базе-источнике будет видно только то, что выполняются некие методы. Вы не отловите, какой там код в какой момент пришел.

• Плюс вы постоянно пересылаете весь код и параметры, что тоже нехорошо. Это то же самое, как если вы придете в библиотеку, положите перед библиотекарем три тома «Войны и мир» и спросите: «Что написано во втором томе на 300-й странице в пятом параграфе?» Получается, что вам, чтобы спросить какую-то вещь, нужно постоянно носить эти книжки. Это тоже не совсем хорошо.

• И возможность потерять все свои данные – я про это уже говорил.

Пример интеграции мобильного приложения и HTTP-сервиса

В заключение хочу вам показать удачный пример разработки с использованием HTTP-сервисов с последнего места работы.

Стояла задача создать мобильное приложение, которое будет обмениваться с ERP. Мы планировали его устанавливать на планшеты пользователей и настраивать силами сотрудников ИТ-отдела.

Для этой цели у меня в ERP был создан план обмена, на узле которого хранится не логин/пароль, а некий сформированный хэш. И с мобильного приложения тоже гоняется не логин/пароль, а некий хэш. Эти хэши сравниваются и обмен производится только при их совпадении.

Чтобы мобильное приложение могло обмениваться информацией с основной системой, я использовал свою подсистему с универсальными HTTP-сервисами PAPI, про которую уже рассказывал на митапе в Екатеринбурге. У нее есть:

• алгоритмы и методы – это отдельные справочники;

• различные методы логирования;

• запуск фоновых заданий для алгоритмов.

В справочнике «Методы» описывается, что HTTP-сервис должен получить, как обработать данные и что отдать. Для методов есть:

• возможность версионирования;

• можно указать конкретный метод, который будет обработан;

• на закладке «Параметры» рассчитываются параметры, которые будут использованы на закладке «Вычисления»;

• указывается алгоритм, который формирует ответ от базы;

• можно задать заголовки ответа и т.д.

На слайде вы видите отчет на планшете – этот отчет был сформирован через HTTP-ответ от метода.

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

Заключение

В качестве вывода хочу сказать, что HTTP-сервисы – это больше друг, чем враг.

HTTP-сервисы ускоряют разработку, делают нашу жизнь проще.

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

Если вы еще не используете HTTP-сервисы, попробуйте, это очень удобно. Но не повторяйте чужих ошибок, не создавайте очередных «Выполняторов».

Вопросы

Какие вы можете порекомендовать средства для хранения паролей к внешним сервисам, с которыми интегрируется 1С?

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

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

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

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

Вызов внешнего сервиса делаем таким образом

УстановитьПривилегированныйРежим()
// Прочитать секрет из параметра сеанса
УстановитьПривилегированныйРежим(Ложь)
ВызватьВнешнийСервис

Если базу выгрузить, то секреты никуда не утекут.

Какие VPN-сервисы рекомендуете для внутренних сервисов? Или лучше написать свой?

OpenVPN – самый распространенный, используем его.

Как правильно выставлять сервис наружу? Лучше всегда закрывать веб-сервисы, которые выдаются наружу? Или в каких-то случаях не закрывать?

Наружу HTTP-сервис выставлять не очень хорошо. Здесь все зависит от квалификации ваших администраторов.

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

Если вам нужно обмениваться с сайтом или сторонним сервисом, есть хорошие средства, я про них в докладе уже упоминал.

А есть какие-то готовые инструменты для защиты базы от внешнего доступа? Какими сервисами можно воспользоваться 1С-нику?

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

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

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