Что по нагрузке? В статике сервисы не пожирают процессор больше чем на 15-20% (Основной потребитель сервис транскрипции, без него 10%). ОЗУ тоже в порядке, 900мб из 4GB.

Поставили поверх основных сервисов еще дополнительно Portainer (аналог докера десктопа, но с чуть меньшим функционалом), grafana + prometeus для метрик, вместе со всем без сервисы транскрипции сейчас 1.1gb потребление ОЗУ и 16%CPU. Ну это мелочи. Сейчас начнем уже тестировать в открытую с нормальным трафиком.

Ошибки

Ох их было много. Ну кто-же знал что например пути для медийки будут разные. И вот одна картинка аватарки руинила вообще весь UI. Потом пути не правильно парсились - исправили. Часть функционала не хотела работать должным образом - переписали ряд мелких модулей. Например из такого прикольного - система прав пользователей. Запускаешь на локалке под 2 учетками - все работает, сервисы те же самые. Компилируешь прилу, запускаешь с сервера - ну вот не обновляются они в real time и все. А проблема была в одной строке ws, которая за собой тянула просто уйму компонентов. Нашли, разобрались и все заработало. Сейчас 97% примерно функционала работает должным образом. Есть еще проблемы - решаем.

Баги

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

Опять же как пример: Есть у нас сервис Emoji который позволяет создавать свои наборы эмодзи и применять их как в сообщениях, так и в реакциях. Вот rout который отвечает за создание пака - скопировался, а route который отвечает за отправку и получения медия - не перенесся. Долго искал проблему. Тем более интерфейса нету никакого, а в лине я вообще нуб. Нашел, написал скрипт который сам заливает по SSH файлы, проверяет на соответствие, и если нет - дозаливает. Почему так - не знаю, но хотелось бы узнать.

И всякие мелкие тоже повсплывали недочеты, права, Pub\sub события и тп.

Первый взлом

Вот тут я вообще офиг и ушел на неделю читать про безопасность и то как порты влияют на доступ извне и бла-бла-бла. В общем, неделю две назад стали замечать что наша база вечно дропается раз в день. Ну казалось бы не жалко, дропайся, посмотрели Volume в докере, все стоит, дропаться не должна, подумали что косяк у яндекса. А вот и нифига. Решил я значит залезть в БД и глянуть логи. Оказалось что кто-то обычным перебором IP и портов залез в БД (Да, я открывал на нее порт, что бы компас подрубить и смотреть данные тестовые). И вот он у себя видимо поставил скрипт на повтор и дропал нам базу. И самое смешное создавал там новую БД с коллекцией README в которой была только 1 запись, цитирую "Кинь биток пожалуйста иначе солью БД". Поржали мы с этого и пошли капать как нам изолировать все. Оказалось что в первоначально версии я задумался о бэк безопасности от эксплойтов, но оставил прямые эксплойти в Compose докера и еще открыл порты. Теперь у нас полная изоляция через NGINX и 3NAT-a. Доступ есть только у нашей команды по нашим IP которые не статичны (Да-да, приходиться раз в сутки менять IP в доступах что бы можно было подключаться). Порты у сервисов теперь проставляет только Docker и автоматически это делает.

Что имеем по итогу:

Мы сейчас собрали живое приложение, устранили большинство эксплойтов и багов.

Добавили лобби для голосовых комнат

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

Доработали "Заметки" к сохраненным сообщениям. И нет они не локальные, все лежит на сервере.

А что у нас по задержкам ответа:

Есть пара мест, но тут мы знаем в чем проблема. Играет 2 вещи:

1. Это порядок запросов (исправляем). Фронт открывает на эти запросы 2 тоннеля и пока один не отработает второй не начнет гнать данные. Но тут больше архитектурный подход

2. Куча подкапотных запросов из которых часть так же идет несколькими туннелями вместо одного. Тут не все получиться решить, но сократить где-то на 40% время запроса - думаю сможем.

Задержка в звуке, тестировали на 9 человек - вообще минимальная 30-100мс. Практически говоришь и сразу слышишь собеседника.

Ах, да. Мобилки. Мобилок пока не будет. Т.е. они готовы, но надо стилевые файлы править под новые функции, не делали пока что. Как бы работают нормально, но есть косяки. Да и в ПК версии тоже косяки будут. Но сил самим 100 раз тыкать одно и тоже уже нету.

Шифрование. В коде оно реализовано для 1:1 общения, но мы его выключили. Нам не нужны проблемы в тв.Майором на этапе тестирования.

Сбор данных и метрик. Их нет. Ну точнее как нет, ради безопасности ваших доступов мы собираем только слепок метаданных пк. Но не для их хранения, а для того что бы на этой основе составить пары ключей доступа и вам не приходилось 100 раз в день вводить логи + пароль - получать ключ входа на почту и тд. Т.е. один раз запрашиваем данные при авторизации, создаем пару ключей, далее рефрешим их и проверяем совпадают ли ваши текущие данные с теми что были отправлены заранее. Если нет - релог. Рефреш раз в Х секунд (минут). Больше мы ничего не запрашиваем. За VPN не бойтесь - не смотрим, нам это не надо. Если вдруг будет много возмущений и слов "Да нам не нужна эта защита я хоть 1000 раз в сутки готов вводить код" - таких будет большинство - отключим и пусть любой подменяет ваш токен.

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

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

Сегодня рассмотрим ситуацию, в которой оказываются многие, когда переносят 1С:Документооборот в облако. Кажется: взял виртуальный сервер, поставил туда 1С — и всё работает. Но есть один нюанс, про который узнаешь либо от ИТ-специалиста, либо от проверяющих органов.

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

Тяжелая артиллерия: как не запутаться в 152, 242, 1119 и 21

Многие думают, что вопрос с персональными данными регулируется одним-единственным законом — 152-ФЗ. На самом деле это целая цепочка из нескольких документов, и проходить ее нужно последовательно. Вот как это выглядит на практике.

Шаг 1. 152-ФЗ — главный закон о персональных данных. Он определяет, кто такой оператор (то есть вы, если храните и обрабатываете ПДн), какие у вас обязанности и что будет за их несоблюдение. Без понимания этого документа остальные не имеют смысла.

Шаг 2. 242-ФЗ — поправка про локализацию. Согласно поправке, собирать, хранить и обрабатывать персональные данные граждан России нужно на серверах, которые физически находятся в России. Это как раз то, что закрывает обычный российский ЦОД. Но только это — и ничего больше.

Шаг 3. Постановление Правительства № 1119 — уровни защищенности. Здесь начинается самое интересное. Система с ПДн получает один из четырех уровней защищенности:

• УЗ-4 — низший (например, только ФИО и телефоны, небольшое количество людей);

• УЗ-3 — средний;

• УЗ-2 — высокий;

• УЗ-1 — высший (спецкатегории данных, большой объем, высокие риски).

Вы сами определяете уровень защищенности специальным документом: он зависит от трех вещей: какие именно данные вы обрабатываете (просто ФИО или еще и данные паспортов, а может, и медицинские данные), сколько людей затронуто и какие угрозы для вас актуальны.

Шаг 4. Приказ ФСТЭК № 21 — что конкретно делать. Под каждый уровень защищенности в этом приказе прописаны конкретные меры. Например, для УЗ-4 — одни требования, для УЗ-2 — другие: обязательное шифрование, сертифицированные средства защиты, отдельный контроль доступа и так далее.

Самое важное про порядок действий: нельзя пропустить ни один из шагов. Сначала вы определяете, какие данные у вас обрабатываются и где. Затем разрабатываете модель угроз — смотрите, что именно может пойти не так: кто и как может получить доступ, какие каналы утечки существуют. И только на основании трех вещей — типов персональных данных, актуальных угроз и количества субъектов — определяете и актом закрепляете уровень защищенности. Далее под этот уровень реализуете конкретные меры из приказа № 21.

Отдельно про аттестацию. Аттестация обязательна для ГИС (Государственная информационная система) и для тех систем, где это прямо установлено нормативно или условиями взаимодействия с государственной системой. Для обычной информационной системы персональных данных аттестация, как правило, не обязательна, а проводится добровольно или по специальному требованию.

Что это значит на практике? Если вы выбираете не свое железо в собственном ЦОДе, а облачную модель — то аттестованное облако становится практически единственным способом законно работать с персональными данными. Для обычного публичного облака или хостинга вы никогда не сможете обеспечить требования по защите на уровне ЦОДа, гипервизоров и виртуализации — провайдер просто не предоставит для этого нужных средств и документального подтверждения.

Аттестованное облако — это готовый инфраструктурный слой, который уже прошел проверку. Вы платите — и вам не нужно самим всё это проектировать и тратиться на строительство с нуля. Удобно, но важно понимать: аттестация закрывает только фундамент, а не весь дом целиком.

Матрешка ответственности: кто за что в ответе (спойлер: провайдер меньше, чем вы думаете)

Соответствие 152-ФЗ — это всегда совместная работа. Разложим, кто за что отвечает.

Инфраструктура — зона ответственности провайдера защищенного облака. Провайдер должен обеспечить физическую защиту ЦОДа, защиту среды виртуализации и гипервизора, сегментацию и изоляцию сетей, межсетевой экран на периметре, обнаружение вторжений, защиту каналов администрирования, а главное — использовать средства защиты, сертифицированные ФСТЭК и ФСБ. Это то, чего у обычного облака нет, а у защищенного — есть из коробки.

Но подходы у провайдеров различаются. Часто защищенное облако закрывает межсетевой экран и систему обнаружения вторжений (МЭ+СОВ) только для своей управляющей инфраструктуры — клиенту приходится разворачивать и обслуживать свои МЭ+СОВ самостоятельно. Есть и другой подход, например, у Рег.облака: когда провайдер берет на себя и эту настройку, давая клиенту готовый периметр. При выборе стоит обращать на это внимание.

Гостевая ОС виртуальной машины — ваша зона ответственности. У вас есть два пути: либо использовать сертифицированную операционную систему, либо установить на обычную ОС сертифицированное средство защиты от несанкционированного доступа (СЗИ). В любом случае также потребуются антивирус, своевременные обновления, включенная регистрация событий и ограничения на запуск программ.

Приложение 1С:Документооборот — ваша зона ответственности. Внутри самой 1С вы настраиваете роли и разграничение прав, ограничение доступа на уровне записей, парольную политику, защищаете тома хранения файлов (про них часто забывают), контролируете выгрузки, печать и обмен, а при необходимости — включаете шифрование.

Организационный слой — ваша зона ответственности. Нужно разработать модель угроз, актом определить уровень защищенности (УЗ), утвердить политику обработки персональных данных, собрать согласия от сотрудников и клиентов, назначить ответственного за обработку ПДн, зарегистрироваться в реестре операторов Роскомнадзора, подготовить регламент реагирования на инциденты и подписать с провайдером договор-поручение по статье 6 №152-ФЗ, а также регулярно проводить оценку эффективности принятых мер защиты — потому что мало внедрить, надо еще доказать, что это работает.

Так, обычный облачный сервер не покрывает даже первый слой: средства защиты не сертифицированы, а договор-поручение провайдер с вами не заключит — потому что необходимые меры защиты не предусмотрены, и такое облако по закону просто не подходит для хранения персональных данных. Защищенное облако охватывает первый слой целиком и оформляет поручение. Причем, например, Рег.облако закрывает самый сложный с точки зрения сертификации и требований слой. Это заметно упрощает подготовку проектной документации: вы можете делать отсылки к уже реализованным мерам и процессам защиты. Но слои со второго по четвертый в любом случае остаются за вами.

Чек-лист: какое облако выбрать под 1С:Документооборот

Пролистайте пункты. Если хотя бы на один ответили «да» — вам нужно защищенное облако.

1. Есть ли в системе персональные данные?

• ФИО сотрудников, паспорта, СНИЛС, ИНН, адреса, телефоны;

• кадровые приказы, трудовые договоры, больничные, заявления;

• сканы паспортов контрагентов (физлиц) или доверенности с ФИО.

✅ Если да — вы оператор ПДн. Обычное облако не подходит.

2. Важна ли защита от атак и взломов?

✅ Если да — защищенное облако дает сертифицированные средства защиты. У обычного облака их нет.

3. Планируете ли рост?

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

✅ Если да — лучше заложить защищенное облако сразу.

Когда можно остаться на обычном облаке или свом сервере? Таких случаев мало, но они есть. Например, если в системе абсолютно нет персональных данных (только юрлица, ИНН/КПП компаний, счета без ФИО). Вы готовы должны быть готовы взять на себя полную настройку ОС, СЗИ, МЭ+СОВ и обслуживание, а бюджет критически ограничен.

Но даже если рассматривать вопрос шире, без привязки к 152-ФЗ: защищенное облако объективно безопаснее. А такие важные для работы организации системы, как 1С:Документооборот, лучше в любом случае размещать в надежном месте — независимо от того, есть там формально ПДн или нет.

Итог: с чего начать, чтобы не получить штраф

Обычный облачный сервер решает только один вопрос — локализацию данных в России. Это необходимо, но недостаточно. 1С:Документооборот почти всегда работает с персональными данными, а они находятся не только в базе, но и в файлах, поисковом индексе и журналах.

Защищенное облако покрывает инфраструктурный слой и оформляет договор-поручение, а всё остальное — настройку ОС, самой 1С и документы — остается за вами. И это не вина провайдера, просто так прописано в законе. Самые дорогие ошибки случаются не там, где забыли включить шифрование, а там, где неправильно поняли, кто за что отвечает, и какой уровень защищенности вам нужен. С этого стоит начинать.

Что касается защищенного Рег.облака — оно как раз размещено в изолированном сегменте дата-центра, имеет аттестат по высшему уровню УЗ-1 и соответствует приказам ФСТЭК № 21. Защита построена на сертифицированных ФСТЭК и ФСБ средствах, с оператором подписывается договор-поручение.

А как у вас организована работа с персональными данными в 1С? На что обращали внимание в первую очередь?