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

11.05.22

Администрирование - Информационная безопасность

HTTP-сервисы ускоряют и упрощают разработку обмена данными между 1С и другими приложениями. Но нельзя забывать, что HTTP-сервис – это дверь в информационную систему. О том, как обеспечить безопасность HTTP-сервиса и не оставить лазеек злоумышленникам, на митапе «Безопасность в 1С» рассказал заместитель начальника отдела разработки ГКО PRO Дмитрий Сидоренко.

В 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С".

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

AUTO VPN (portable)

Информационная безопасность Платные (руб)

Автоматизация подключения пользователей к удаленному рабочему месту или сети посредством создания автоматического VPN (L2TP или L2TP/IPSEC и т.д.) подключения без ввода настроек пользователем (с возможностью скрытия этих настроек от пользователя). Программа автоматически выполняет подключение к VPN серверу и после успешного коннекта , если необходимо, подключение к серверу удаленных рабочих столов (RDP).

1200 руб.

24.03.2020    14399    22    32    

33

Настройка аутентификации в 1С с использованием стандарта RFC 7519 (JWT)

Информационная безопасность Платформа 1С v8.3 Бесплатно (free)

Рассмотрим в статье более подробную и последовательную настройку аутентификации в 1С с использованием распространенной технологии JWT, которая пришла в программу в платформе версии 8.3.21.1302.

27.02.2024    2608    PROSTO-1C    9    

29

Device flow аутентификация, или туда и обратно

Информационная безопасность Платформа 1С v8.3 Абонемент ($m)

Интеграционные решения стали неотъемлемой частью нашей жизни. Правилом хорошего тона в современных приложениях является не давать интегратору доступ к чувствительным данным. Device flow позволяет аутентифицировать пользователя, не показывая приложению чувствительные данные (например: логин и пароль)<br> Рассмотрим Device flow аутентификацию, в приложении, на примере OpenID провайдера Yandex.

1 стартмани

27.10.2023    1618    platonov.e    1    

23

Анализатор безопасности базы сервера 1С

Информационная безопасность Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

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

5 стартмани

24.04.2023    5438    14    soulner    7    

29

Двухфакторная аутентификация в 1С через Telegram и Email

Информационная безопасность Платформа 1С v8.3 1С:ERP Управление предприятием 2 Абонемент ($m)

1С, начиная с версии платформы 8.3.21, добавили в систему возможность двойной аутентификации. Как это работает: в пользователе информационной базы появилось свойство «Аутентификация токеном доступа» (АутентификацияТокеномДоступа во встроенном языке), если установить этот признак и осуществить ряд манипуляций на встроенном языке, то появляется возможность при аутентификации отправлять HTTP запросы, которые и реализуют этот самый второй фактор. Данное расширение позволяет организовать двухфакторную аутентификацию с помощью электронной почты или мессенджера Telegram.

2 стартмани

08.12.2022    5968    32    Silenser    12    

23

История одного взлома или проверьте вашу систему на безопасность

Информационная безопасность Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От клиента клиенту, от одной системы к другой, мы вновь и вновь встречаем одни и те же проблемы и дыры в безопасности. На конференции Infostart Event 2021 Post-Apocalypse Виталий Онянов рассказал о базовых принципах безопасности информационных систем и представил чек-лист, с помощью которого вы сможете проверить свою систему на уязвимость.

26.10.2022    9245    Tavalik    46    

113
Отзывы
10. dsdred 3251 14.05.22 10:01 Сейчас в теме
(9)ещё раз.
Логин и пароль Первоначально создаётся в основной базе.
На планшете хеш создаётся в момент проверки логин и пароля.
На планшете хранятся только настройки для подключения.
Грубо говоря данные на планшете по садику конкретному не хранятся.
Если ввести логин пароль от другого Садика тогда придут данные по обедам с другого Садика.

Логины и пароли Создаются в основной базе где сразу проверяется хеш на совпадение, если он совпадет тогда не даст сохранить логин и пароль.

Поэтому на одном садике может быть несколько планшетов или один планшет на несколько садиков.
Cyberhawk; +1 Ответить
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. dsdred 3251 11.05.22 11:55 Сейчас в теме
Вы говорите про то, как хранятся пароли внутри 1С, а снаружи? Если нужно обмениваться паролем между командой разработки и инфраструктурщиками?

Upd. Очень понравилась программа KeePass
heldon; shtinalex; +2 Ответить
2. rabid_otter 134 12.05.22 23:09 Сейчас в теме
hashicorp vault есть же для паролей
3. Cyberhawk 135 14.05.22 09:22 Сейчас в теме
план обмена, на узле которого хранится не логин/пароль, а некий сформированный хэш. И с мобильного приложения тоже гоняется не логин/пароль, а некий хэш. Эти хэши сравниваются
Как-нибудь решается коллизия (если хеши двух разных пользователей совпадут)?
4. dsdred 3251 14.05.22 09:25 Сейчас в теме
(3) В моменте создания узла под пользователя этот момент проверяется.
5. Cyberhawk 135 14.05.22 09:27 Сейчас в теме
(4)
моменте создания узла под пользователя этот момент проверяется
А узел создается по инициативе мобильного приложения?
6. dsdred 3251 14.05.22 09:29 Сейчас в теме
(5)нет. Тут ситуация такая:
Контора выигрывает тендер на обеспечение питания Садика.
Под садик создаётся узел и в садик уезжает настроенный планшет.
7. Cyberhawk 135 14.05.22 09:32 Сейчас в теме
(6) Т.е. на планшете хеш не создается, а вводится готовый (при первичной настройке)?
8. dsdred 3251 14.05.22 09:38 Сейчас в теме
(7) на планшете вводятся настройки подключения под служебной учеткой и адрес для обновления приложения.
Хеш на планшете создаётся в момент проверки логин пароля при авторизации.

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

П.С.
У меня есть статья мобильное приложение на 1с, там про это же приложение есть информация и картинки.
9. Cyberhawk 135 14.05.22 09:48 Сейчас в теме
Пользователь вводит логин пароль и наживает вход.
Формируется хеш и отправляется в проверку
Так вот я и спрашивал про этот момент: если на планшете хеш-функция создала такое значение хеша, которое в основной базе уже "привязано" совершенно к другому пользователю, то как разрешается эта ситуация?
10. dsdred 3251 14.05.22 10:01 Сейчас в теме
(9)ещё раз.
Логин и пароль Первоначально создаётся в основной базе.
На планшете хеш создаётся в момент проверки логин и пароля.
На планшете хранятся только настройки для подключения.
Грубо говоря данные на планшете по садику конкретному не хранятся.
Если ввести логин пароль от другого Садика тогда придут данные по обедам с другого Садика.

Логины и пароли Создаются в основной базе где сразу проверяется хеш на совпадение, если он совпадет тогда не даст сохранить логин и пароль.

Поэтому на одном садике может быть несколько планшетов или один планшет на несколько садиков.
Cyberhawk; +1 Ответить
11. darkinitr0 34 19.05.22 17:59 Сейчас в теме
ваше описание отличий GET и POST с выводами что является безопасным а что нет, что для получения данных а что для изменения - является иллюзорным и некорректным.
Все что передается без шифрования является перехватываемым и соответственно не безопасным.
12. dsdred 3251 19.05.22 18:14 Сейчас в теме
(11)Вы путаетесь в терминах. Мой посыл о другом, можно почитать например тут: https://www.google.com/amp/s/htmlacademy.ru/blog/best/get-vs-post%3famp=1

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

Про шифрование это про безопасность впринципе. Про это я тоже рассказывал.
Оставьте свое сообщение