Отчет о проделанной работе программиста 1с
Приветствую. Продолжаем изучать объекты на дереве конфигурации и на очереди "Отчет" (Рисунок 1).
Создание отчета ничем не отличается от создания любого другого объекта дерева конфигурации: через контекстное меню или через значок плюсик.
Отчет - это объект дерева конфигурации, который предназначен для обработки данных и вывода их в виде, удобном пользователю.
Как и в жизни, отчеты хранят какую-то информацию, так и наши отчеты будут хранить информацию, которую хочет видеть пользователь.
Приступим к созданию отчета. Перед нами стоит задача: необходимо вывести список всех сотрудников по предприятию.
Добавляем отчет и называем его "Список сотрудников" (Рисунок 2).
Теперь необходимо нажать на кнопку "Открыть схему компоновки данных" (Рисунок 3).
Схема компоновки данных (СКД) - это специальный механизм (инструмент) платформы, который позволяет с легкостью создавать отчеты, даже не имея опыта разработки.
В открывшемся окне нажимаем "Готово"(Рисунок 4).
В следующем окне нужно подготовить все для создания отчета. Для этого создадим запрос (Рисунок 5).
После этого переходим в низ открывшегося окна и нажимаем кнопку "Конструктор запроса" (Рисунок 6).
В открывшемся окне нужно выбрать тот объект, по которому вы хотите сделать отчет, в данном случае нас интересует отчет по сотрудникам, значит выбираем справочник "СписокСотрудников" (Рисунок 7).
Перетаскиваем справочник (или двойным нажатием или на стрелочку вправо, выделив справочник) во второй столбец (Рисунок 7).
Теперь необходимо раскрыть элементы этого справочника и выбрать там те, которые мы хотим видеть в отчете (Рисунок 8). Перетаскиваем в столбец "Поля" нужные элементы (Рисунок 8).
После этого нажимаем "Ок" и в поле "" появится запрос (Рисунок 9).
Переходим на вкладку "Настройки" (Рисунок 10).
На этой вкладке нужно создать сам отчет (Рисунок 11). Создаем группировку.
В новом окне нажимаем "Ок", ничего не меняя (Рисунок 12).
После этого идем вниз и перетаскиваем нужные поля (Рисунок 13).
В итоге у вас должно получиться так (Рисунок 14).
После этого закроем все окна, отчет готов, но нужно добавить его в одну из подсистем, иначе пользователь не сможет им пользоваться (Рисунок 15).
Запустим пользователя, перейдем в подсистему и найдем наш отчет (Рисунок 16).
Как видите, отчета нет. Нужно нажать кнопку "Сформировать" и отчет появится (Рисунок 17).
Таким образом, нажимая на кнопку "Сформировать" отчет будет формироваться каждый раз по новым данным, которые пользователь может добавлять каждый час или день.
Создание отчета завершено - это самый простейший отчет, который может создавать платформа. Это минимально, что она может и ее функционал намного больше, чем мы сделали сейчас. Но все это еще впереди, пока остановимся на этом.
На этом статья урока подходит к концу. Попробуйте выполнить все действия, которые описаны в этом уроке. Если что-то не получается, то вы всегда сможете написать вопрос о том, что вам непонятно или вернуться к предыдущим урокам и посмотреть их - ссылки внизу!
В одной из компаний, где я работал, была очень строгая отчётность. Все рабочие часы должны были быть закрыты в отчётности какой-то задачей, а отчёты сдавались ежедневно. В общем, человек ко всему привыкает, и вполне можно было вспомнить, чем ты занимался сегодняшний день и всё расписать. Но однажды нас попросили дополнительно составить такую отчётность за предыдущие полтора месяца. Естественно, такое пожелание вызвало некоторые затруднения у сотрудников.
Для меня же это выполнить это требование было довольно легко. Просто у меня всё записано. Каждый рабочий день.
Отчётность позволяет оценивать свою эффективность
Кто-то обновляет репозиторий каждый день, кто-то не уходит, пока не завершит задачу. Ежедневные отчёты выглядят чем-то вопиющим только в отрыве от этого ряда. От себя могу сказать, что подобная практика очень сильно мотивирует сосредоточиться на работе, и я продолжил составлять отчёты даже когда перешёл на другую работу.
Что ты скажешь себе по окончании трудового дня, если у тебя список задач пустой? Хорошо, если день завершился решением задачи, а если нет? Чем ты вообще занимался сегодня, на что потратил своё время?
Теперь можно проанализировать свой рабочий день, понять, на что уходит время, и тратить время более эффективно.
Учёт позволяет выделить съедающие время задачи
Как-то, ещё до внедрения этой схемы, когда я работал на фрилансе, я не понимал, почему за большое время решается так мало задач. Я подозревал, что я много разговариваю с потенциальными клиентами, но когда я стал фиксировать это время, я поразился, насколько это были громадные потери! Тогда я ограничил своё общение с потенциальными заказчиками десятью минутами, тогда как ранее мог разговаривать с ними до часа, а ведь они могли и не вернуться.
Эффективность работы сразу намного возросла.
Отчётность позволяет вести базу знаний
Кроме этого, записываются не только задачи, но и методы их решения, что позволяет накапливать опыт и использовать эти решения в дальнейшем, даже если прошло несколько лет. Особенно это полезно для разработчика широкого профиля, поскольку языков и технологий много, решение задачи можно себе представлять, а вот конкретный синтаксис может забываться, и подобные базы знаний, в которые превращаются эти отчёты, становятся весьма полезными.
Ведение отчётности не тратит, а экономит время
Может показаться, что ведение базы своих действий занимает очень много времени, но это не так. Когда мне нужно было это оценить, в своих задачах я стал отмечать и то время, которое тратилось на ведение отчётов. И в среднем это время оказалось равным 25 минут в рабочий день. С учётом того, что отчёты зачастую составлялись весьма общирные, и это давало возможность использовать наработки повторно, это в конечном итоге оборачивалось не потерей времени, а наоборот, его экономией.
Микрошаги
По прошествии времени я усовершенствовал эту систему, и преобразовал её в метод, который я назвал микрошагами. Например, нужно применить некое решение, которое уже описано полгода назад. Но условия могут меняться, и может быть непонятным, почему на том этапе именно это решение было применено, а не какое-то другое. Эффективность повторного использования решения снижалась. Тогда я ввёл причинно-следственный элемент в отчётность, ограничил одно описываемое действие двадцатью минутами работы. Это был эксперимент, но он удался!
Оказалось, любую задачу можно разбить на такие подзадачи и уложить её в требуемое время. Да, это первое требование для эффективного решения задач, разбиение на подзадачи, но я, дополнительно, добавил к подзадачам причины, по которой они делаются, и организовал вложенную структуру, продвигаясь по которой, можно проследить, почему было применено то или иное решение.
Страх узнать правду
А ещё это позволяет оценивать собственную эффективность, и конкретизировать, в чём именно нужно подтянуть свои знания, если какой-то микрошаг занимает неоправданно большое время по сравнению с тем, какое должен был занимать. Конечно, для этого нужно не бояться взглять в глаза той правде, которую покажет собственная отчётность.
Пример микрошагов
Пример микрошагов. Информационно данный конкретный пример не имеет никакого смысла кроме разработчиков данного приложения. Этого пример только показывает, каким образом оформляются микрошаги для решения некоей задачи.
Если микрошаги находятся на одном уровне, то они возникали и решались последовательно. Если происходит переход на один уровень вложенности, это означает, что для выполнения этого микрошага нужно выполнить другие микрошаги, и после их выполнения, решится и задача более высокого уровня. Если в какой-то момент происходит переход на меньший уровень вложенности, значит, с помощью вложенных микрошагов выполнена более вышестоящая задача, которая находится на том же уровне вложенности, на который проихошёл переход.
Использование микрошагов для уяснения пробелов в знаниях
Анализ микрошаговой отчётности позволяет выявить узкие места в системе знаний разработчика, и, по-идее, дальнейшим развитием этой системы будет систематизация этих узких мест и уделение времени на устранение пробелов в этих областях. Само выявление не является трудной задачей: нужно увидеть, какие шаги требуют дополнительных действий и занимают достаточно времени для их решения.
Когда над проектом работают десятки человек, то трудно уследить за тем, кто чем занимается. Если же команда распределена по странам и/или городам, то составить представление о том, чем занимаются люди из другого города и/или другой страны, становится ещё сложнее.
Цели и задачи
- Своевременно обнаруживать препятствия, с которыми столкнулись инженеры при выполнении своих заданий.
- Находить зависимости между заданиями разных инженеров.
- Своевременно определять, какой задачей занимается инженер – той, что поставил ему менеджер или ведущий программист, или той, что он выдумал себе сам.
- Объективно оценивать результаты работы каждого сотрудника.
Правила
Шаблон отчёта
В ежедневном отчёте сотрудник должен последовательно ответить на три вопроса:
1. Что блокирует мою работу?
При ответе на этот вопрос инженер перечисляет риски, угрозы, препятствия или зависимости, которые блокируют его работу над текущим заданием.
Задача «67 – Навигационная система – Главное меню – Обновить иконки» заблокирована из-за отсутствия новых иконок
Задача «83 – Навигационная система – Поиск по почтовому индексу – Добавить экран поиска по почтовому индексу» не может быть завершена, т.к. работа над задачей «82 – Навигационная система – Разработать модуль поиска по почтовому индексу» ещё не начата
2. Что я делал сегодня?
Отвечая на этот вопрос, инженер перечисляет задания, которыми он занимался в текущий рабочий день. Информация о задании должна включать идентификатор задания, название и, по-возможности, гиперссылку на его описание в системе контроля заданий. Название позволит читателю отчёта (менеджеру или другому инженеру) составить представление о том, чем занимался данный человек. Идентификатор задания и гиперссылка помогут быстро найти дополнительную информацию по заданию в системе контроля заданий.
119 – Навигационная система – Построение маршрута – Разобраться, почему не используется КАД при построении маршрута от пр. Непокорённых до Ладожского вокзала при включённой оптимизации по времени
91 – Навигационная система – Поиск адреса – Разобраться, почему находятся несколько пересечений Невского пр. и Казанской ул.
3. Что я собираюсь делать завтра?
Отвечая на третий вопрос, инженер перечисляет задания, к которым он собирается приступить на следующий рабочий день, или же указывает, что задания отсутствуют, если заданий нет.
131 – Навигационная система – Навигация – При движении по маршруту стрелка не должна перескакивать на перпендикулярные улицы и менять своё направление на 90 градусов
107 – Навигационная система – Навигация – Разобраться, почему при движении по Гражданскому пр. стрелка прилипает не к основному дорожному элементу, а к «карману»
После очередной беседы с руководством возник вопрос в ведении отчётности и планировании работы.
При этом, руководитель, конечно же, ничего не понимает в программировании, а мне лень писать ежедневные/еженедельные отчёты о состоянии дел.
В компании, где я работаю, есть всего два web-разработчика и немалое количество проектов, которые надо либо переделывать полностью, либо поддерживать их и исправлять огромное количество багов (пока до них не дойдёт очередь полного обновления).
В силу того, что мы ребята молодые и опыта в ведении отчётности и планировании работы нет, то возник вопрос, как лучше вести отчётность для тех людей, которые не понимают ничего в программировании, но при этом, имеют возможность при необходимости показать своим друзьям-программистам и спросить совета "а чем эти парни занимаются у меня в компании?".
Собственно, вопрос: посоветуйте, какие средства/программы/решения/блокноты/кульбиты/фокусы использовать, чтобы нам было легко и просто жить, и при этом вести отчётность ежедневно или еженедельно?
Есть такая волшебная вещь - Trello. По сути это доска задач со стикерами только в электронном виде. Для небольших команд самое то. Отчёты можно выгружать в json или excel, либо просто дать доступ начальству к доскам проектов чтобы оно видело статус работ в реальном времени.
Если Trello приживётся, то потом можно перейти на Jira или redmine.
Trello, Basecamp, Jira, Asana и т.д.
Все эти сервисы позволяют вести проекты, указывать задачи, подзадачи, что сделано что не сделано, вести переписку по каждой задаче, комментировать, учитывать время, показывать отчеты и графики.
Спросите на прямую у своих менеджеров.
От себя могу поведать так.
Как ПМ могу ответить, что перед постановкой задач на разработку я составляю список фич.
Разбиваю проект на модули или компоненты и каждый модуль набиваю фичами.
Выглядит это примерно так:
Пользователи:
Создание пользователя
Удаление пользователя
Деактивация пользователя
И так на каждый модуль. В итоге в зависимости от проекта собирается от 50 до 200 фич.
Свои отчеты так и собираю, только фичи мне известны. А собираю в основном часы. Каждая фича у меня оценивается перед началом разработки и я имею эталонное время. Добавив к которому риски и корреляцию на опыт, могу увидеть время необходимое на разработку модуля или отдельно взятой фичи. Соотв. отчетность собираю по трудозатратам на фичу-модуль.
Попробуй составлять отчет в виде какая фича переделывалась или делалась с нуля и сколько было затрачено на это времени.
Вы о чем. Каким боком Скрам подойдет группе из двух человек с целями типа "от забора и до обеда". если у них не то, что Продуктовнера нет, но руководство даже не знает, какие хочет отчеты? Если тут вообще уместно слово подойдет, то тогда уж Канбан. А по хорошему - бежать нужно из этой богодельни :(
@pi314 Ребята не знают как планировать задачи, а также как предоставлять отчетность руководству. Кто-то ведь задачи им ставит, кто-то проверяет, они же не сами по себе работают. Пусть в группе мало человек, но один человек может совмещать несколько ролей. А руководитель компании пусть выполняет роль внутреннего заказчика.
@pi314 Конечно это при условии, что ребята хотят улучшить ситуацию и проявить инициативу (можно объяснить руководство, что это нормальный подход), а так, безусловно, такими вещами руководство должно заниматься, а если ему до лампочки, то бежать надо из такой компании.
@Fandorin Дело в том, что Скрам для групп меньше 5-7 человек полезен, как рыбе зонтик. Для всяких совмещений ролей, процентного участия (на проекте полтора программиста) и прочего креатива, неизбежного в ситуациях, когда для внедрения Скрам нет необходимых предпосылок, существует даже специальный термин "как бы-скрам" (ScrumBut) именно от того, что все это прямо противоречит сути методики. Насколько я понял, проблема не в том, что не знают, КАК планировать, а в том, что никто не берет на себя отвественность сформулировать ЧТО должно быть сделано и каковы приоритеты. Один не разбирается, другому лень (ибо, вероятнее всего, это не оплачивается), а третий (знакомые программисты) все равно не в теме и ни за что не отвечают.
Это очень распространенная ситуация, когда руководство "доверяет" планирование подчиненным. В переводе на человеческий язык это означает "дай мне план, из которого я наконец узнаю, что я от тебя хочу". Ситуация принципиально шизофреническая, и упомянутые консультации со знакомыми программистами гармонично дополняют клиническую картину, означая "я дам этот план на проверку кому-то другому, чтоб узнать, правильно ли это". Классический подход не менеджера, но функционера!
Если руководитель реально хочет чего-то, в чем не разбирается, он найдет того, кто разбирается и чьей компетентности он доверяет, и назначит его планировать, ставить задачи и т.д. и будет с него спрашивать отчеты, и вопрос формы этих отчетов прояснится сам собой. Если этого не происходит, значит никому ничего на самом деле не нужно и незачем огород городить.
@pi314 вы неправильно поняли ситуацию. У нас есть приоритеты и мы (те самые два рограммиста) их понимаем, у нас есть проекты и нам нравится их развивать и мы понимаем, что мы хотим, но у нас нет никакой документации/планов/гайдов и мы просто не делаем никаких прототипов, а сразу кодим. Именно от этого я хочу отойти и начать строить эффективную команду. Да, можно было бы пойти работать в крупную компанию и там научиться всему и только потом идти к тому человеку, который тебе доверяет (а мне мой руководитель доверяет в плане работы, просто ему хочется понимать, за что всё таки он мне платит, потому что условия работы у нас немного лояльные - об этом отдельно ниже) и который готов платить тебе зарплату за то, что тебе нравится и чем ты хочешь заниматься. Но вот так сложилась ситуация, что мой работодатель готов платить мне деньги за то, что я 2 дня в неделю работаю удалённо + 3 дня из офиса, за то, что я могу курить любимый кальян в офисе в любое время и мне ничего за это не будет, главное работу свою делать. Но вот проблема с планированием. Мы не умеем этого делать. Соответственно мы не умеем отчитываться за то, что сделали, потому что в моём понимании это взаимосвязанные вещи. Мы сказали. что сделаем этот сайт за две недели, но когда начали делать оказалось, что не всё так просто. Он нам по силам, но времени намного больше, потому что хочется запилить много плюшек, которые по ходу работы только выплывают. Я понимаю, что это грабли и хочу просто побыстрее через них пройти, чтобы и опыт стал полезным и выработалась удобная нам система функционирования команды. Вопрос только в том, какими ресурсами это устроить.
В третьей части я показал пример обращения ко всем возможным методам, и как работать с длительными операциями.
В четвертой части показал, как работать с порциями.
для обмена данными между информационными системами;
для обмена данными с сайтами и порталами;
Клиент формирует запрос к веб-серверу.
Дальше запрос проходит какие-то проверки – проверяются заголовки, параметры, тело запроса (если сервис использует тело запроса).
Если все проверки пройдены, то выполняется некий метод в вашей конфигурации и формируется ответ с кодом состояния:
обычно, если все нормально отработало, код состояния равен 200;
если что-то пошло не так, код состояния может отличаться;
есть методики, когда используется JSON RPC – в этом случае код состояния всегда равен 200, а в теле запроса в определенной структуре JSON содержится ответ, где в параметре error пишется, какие были ошибки.
Есть ли какая-то универсальная микстура или принцип, как сделать определенные шаги для обеспечения безопасности всех сервисов, которые вы создаете? Такой микстуры, к сожалению, нет. Но есть какие-то практики, которые люди применяют в своей работе.
Настройте регулярное создание бэкапов
Простая проверка администратора на профпригодность – это поручение «Восстанови на тестовой базе вчерашний бэкап». Если администратор сможет восстановить бэкап только месячной давности, нет причин с ним дальше работать. За месяц многое может поменяться, поэтому такие вещи недопустимы, и не дай Бог с вами это произойдет.
Для чего нужен сервис?
Кто конечный потребитель?
Будет ли сервис выставлен наружу?
Эти три простых вопроса позволяют понять, какие вещи необходимо будет произвести для обеспечения безопасности.
GET для безопасных действий, POST для небезопасных
Дальше нужно определиться с тем, по каким методам будет работать ваш сервис – будет ли он использовать только GET или POST, или он будет использовать смешанные методы.
GET вызывает так называемые безопасные действия – он получает параметры и отдает некие данные из информационной базы.
POST предназначен для более опасных действий – если вы хотите передавать логин-пароль, то GET для этих случаев не подойдет, лучше передавать в теле POST.
Чтобы определиться, какой метод вам больше подходит, есть картинка, которая очень наглядно помогает выбрать тот или иной метод.
Повторюсь, что основные минусы GET по сравнению с POST – это то, что запрос можно кешировать, запросы могут оставаться в истории браузера, параметры передаются в URL, и GET не предназначен для передачи больших объемов данных.
Это – наглядный пример MITM-атаки.
Let’s Encrypt – лучше, чем самоподписанный сертификат, но есть минусы
Часто встречается, что приходишь в какую-то крупную организацию, и там используют самоподписанные сертификаты. Если сервисы используются для внутренних целей, этого достаточно. Но если вы собираетесь выставить сервис наружу для обновления какого-то мобильного приложения, такой самоподписанный сертификат не подойдет. Лучше использовать бесплатный сервис Let’s Encrypt.
Но у сервиса Let’s Encrypt есть минусы по сравнению с платными сервисами:
Нет гарантии, что с Let’s Encrypt не случится то же самое, что случилось со Startcom и Wosign. 5 лет назад был случай, что крупные производители браузеров перестали им доверять – эти сертификаты потеряли доверие.
Еще нет гарантии сертификата. Например, если клиент зайдет на сайт, который подтвержден сертификатом платного центра, и потеряет деньги в результате фишинга, то эти платные центры обязуются выплатить некую сумму (от 10 тысяч долларов до 1.5 миллионов долларов).
И основной минус – у Let’s Encrypt сертификаты выдаются на 3 месяца. С другой стороны, есть готовые скрипты, готовые боты, которые продлевают сертификат. Для Apache – это certbot, а для IIS – это win-acme.
Разделите сервисы
Соответственно, если вашу фирму начнут проверять на прочность, вздрогнет вся система, и работать будет невозможно.
Поэтому я не зря изобразил на слайде подводную лодку: если в ней случается пробоина, закупоривается один отсек, а остальная часть подводной лодки продолжает функционировать. Я тоже рекомендую разносить внутренние сервисы на одну машину, а сервисы, которые должны общаться с внешним миром на другую, возможно, даже на несколько машин.
Опубликуйте сервис и настройте на него права
Если вы организовываете внутреннюю сеть, достаточно внутри сети поставить веб-сервер – это может быть Apache, IIS, это может быть 1С:Публикатор или 1С:Линк (это тоже Apache, просто его версия от фирмы 1С с красивым интерфейсом).
К паролям нужно относиться очень бережно – про это я чуть дальше расскажу. Желательно, чтобы у сотрудников были хорошие пароли.
Используйте VPN
Если вам нужно организовать удаленный офис либо объединить в единую сеть магазины или сеть точек общественного питания, используйте для администрирования VPN – этого достаточно.
Организуйте промежуточное звено
Есть варианты с промежуточным сервисом:
Один из таких вариантов был показан на онлайн-митапе «Web-клиенты для 1С». Есть некий промежуточный сервис, написанный на каком-то стороннем языке, этот сервис смотрит наружу, получает запросы от клиентов, организует для этих запросов некие квесты – накладывается фильтрация, проверяются токены, организуется ограничение частоты вызова определенных методов или двухфакторная аутентификация. Только тогда, когда все эти квесты пройдены, запрос идет во внутреннюю сеть. Вариант неплохой, рабочий, многие его используют.
Есть еще вариант с промежуточной базой, которая получает запросы, отслеживает, что в этом запросе все хорошо, и тогда уже передает его во внутреннюю систему.
Получается, что эти промежуточные звенья принимают первый удар на себя, а если с ними что-нибудь случится, ваша информационная база будет в безопасности.
То же самое можно делать и другими средствами:
можно установить файрвол, который ограничивает доступ, делает фильтрацию IP, закрывает порты;
за файрволом можно поставить реверсный прокси, на котором тоже настроены какие-то фильтры – реверсный прокси-сервер может выполнять функцию балансировки – он разграничивает нагрузку между сервисами и дополнительно уменьшает трафик за счет кеширования.
Это тоже рабочий вариант.
Пройдите аудит ИБ
Даже если у вас все отлично настроено, все отлично работает, можно еще произвести аудит информационной безопасности. Это актуально, поскольку система развивается, в ней появляются новые дыры, и их надо своевременно отслеживать.
Какие-то фирмы проводят аудит раз в полгода, кто-то – раз в год. Какие-то фирмы начинают проводить аудит только тогда, когда с ними что-то случается.
Но проводить аудит – дело полезное. Вы получите обратную связь, получите отчет о том, что было проделано, узнаете, какие у вас есть дыры в безопасности. Если у вас нет возможности проводить аудит своими силами, есть сторонние организации, которые этим занимаются.
Проводите постоянный мониторинг
Нужно производить постоянный мониторинг системы. Даже если у вас все работает, следовать правилу «Работает – не трожь» не совсем правильно. Система работает до тех пор, пока вы ее обслуживаете. Соответственно, можно настроить какие-то сборы метрик, можно проверять логирование. В 2019 году на Инфостарте был очень хороший доклад «Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей». Докладчик рассказывал о том, как у них некая нейронная сеть отлавливает некие изменения в системе и на основании этих изменений делает какие-то действия, сообщает о каких-то ошибках.
Если пойти этим же путем, анализировать все эти метрики, логи, то в принципе тоже можно сделать такого автоадминистратора, который все эти вещи будет сам отлавливать. Я думаю, что даже в каких-то крупных ИТ-гигантах такие вещи уже сделаны и успешно работают.
Храните логи в недоступном от злоумышленников месте
О чем еще важно помнить? Допустим, у вас есть логи, которые вы храните не очень защищенно. Логи тоже могут иметь некую конфиденциальную информацию.
Например, в логах хранится заголовок запросов с базовой авторизацией. Соответственно, если злоумышленник получит эти логи, он их без труда декодирует и получит доступ к вашей базе под этой учетной записью.
Относитесь к паролям бережно
Еще раз напомню, что к паролям нужно относиться бережно. В практике моей компании был один случай: до 2018 года у нас администратора не было, состояние системы было подзаброшено, и мы наняли очень хорошего администратора, чтобы он все настроил. А потом директор решил проверить, действительно ли теперь все так хорошо, и обратился к моему коллеге, попросил его за хорошее вознаграждение взломать систему. У меня коллега далеко не хакер, он просто 1С-программист, который знал, что в компании есть некая база, которая опубликована наружу. Он открыл эту базу через браузер, быстро подобрал пароль к учетке пользователя-администратора с правом открытия внешних обработок, вошел в базу, открыл в ней обработку и сделал принтскрины, доказывающие, что у него полный доступ ко всем данным. Пароль был 123.
Как перечеркнуть все усилия по обеспечению безопасности
В феврале этого года я выложил статью «Выполнятор – как я породил монстра и лишился сна!». Это случай из 2017-го года. Я тоже человек грешный, я реализовал некое очень страшное решение через метод «Выполнить()».
Самое интересное, что такие статьи выходят на Инфостарте регулярно, я примерно раз в месяц вижу новую статью с таким решением.
Если я вижу такую статью, я пытаюсь пообщаться с автором и объяснить, почему так делать не стоит – об этом я расскажу дальше.
Все эти «Выполняторы» работают по одному принципу с небольшими отличиями:
кто-то передает текст команды,
кто-то передает текст команды и параметры,
кто-то передает текст запроса и параметры;
кто-то передает просто текст запроса.
Дальше это все попадает в некий метод «Выполнить()», где все это выполняется. Это некий троянский конь, через который с вашей системой можно что угодно сделать, вплоть до очистки всех данных.
Есть статья на ИТС «Ограничения на использование Выполнить и Вычислить на сервере». Если вы решили сделать универсальное решение, то ознакомьтесь с этой статьей, все вопросы уйдут.
Когда я общался с авторами, я интересовался, почему они сделали такое решение:
Некоторые, как и я, хотели выйти из конфигуратора – статья про «Выполнятор» как раз показывает, что так делать неправильно.
Кто-то говорил, что ему не нравится писать код в двух местах – в конфигурации-источнике и конфигурации-приемнике.
Основные минусы «Выполняторов»:
Практически невозможно отловить неоптимальный код. В базе-источнике будет видно только то, что выполняются некие методы. Вы не отловите, какой там код в какой момент пришел.
Плюс вы постоянно пересылаете весь код и параметры, что тоже нехорошо. Это то же самое, как если вы придете в библиотеку, положите перед библиотекарем три тома «Войны и мир» и спросите: «Что написано во втором томе на 300-й странице в пятом параграфе?» Получается, что вам, чтобы спросить какую-то вещь, нужно постоянно носить эти книжки. Это тоже не совсем хорошо.
И возможность потерять все свои данные – я про это уже говорил.
Стояла задача создать мобильное приложение, которое будет обмениваться с ERP. Мы планировали его устанавливать на планшеты пользователей и настраивать силами сотрудников ИТ-отдела.
Для этой цели у меня в ERP был создан план обмена, на узле которого хранится не логин/пароль, а некий сформированный хэш. И с мобильного приложения тоже гоняется не логин/пароль, а некий хэш. Эти хэши сравниваются и обмен производится только при их совпадении.
алгоритмы и методы – это отдельные справочники;
различные методы логирования;
запуск фоновых заданий для алгоритмов.
можно указать конкретный метод, который будет обработан;
на закладке «Параметры» рассчитываются параметры, которые будут использованы на закладке «Вычисления»;
указывается алгоритм, который формирует ответ от базы;
можно задать заголовки ответа и т.д.
Учитывая, что система универсальных методов уже была, на разработку полноценного рабочего окружения для мобильного приложения ушло 3 недели.
Заключение
Плюс заказчик получает готовую функциональность, реализацию которой не нужно оплачивать – все можно сделать силами одного 1С-ника.
Вопросы
Какие вы можете порекомендовать средства для хранения паролей к внешним сервисам, с которыми интегрируется 1С?
1С рекомендует использовать для этого безопасное хранилище. Но я обычно делаю свое хранилище значений. И в нем уже в определенной структуре храню такие вещи.
В кейсе про мобильное приложение, о котором я рассказывал, я не гоняю пароль в явном виде, я просто гоняю некий хэш.
Вы говорите про то, как хранятся пароли внутри 1С, а снаружи? Если нужно обмениваться паролем между командой разработки и инфраструктурщиками? Используете ли вы какие-то сервисы для этого?
Можно хранить секреты в файле на сервере с ограниченным доступом, либо в специальном сервисе. В базу добавляем ПараметрСеанса, в который будем считывать секреты, и запрещаем доступ к этому параметру сеанса.
Вызов внешнего сервиса делаем таким образом
Если базу выгрузить, то секреты никуда не утекут.
Какие VPN-сервисы рекомендуете для внутренних сервисов? Или лучше написать свой?
OpenVPN – самый распространенный, используем его.
Как правильно выставлять сервис наружу? Лучше всегда закрывать веб-сервисы, которые выдаются наружу? Или в каких-то случаях не закрывать?
Если для вас это будет очень больно, лучше этого не делать. Если вы обслуживаетесь у каких-то аутсорсеров, а вас начнут проверять на прочность, то вам нужно будет сначала дозвониться, дождаться, когда специалист с вами через час свяжется, и только потом вам, может быть, помогут. В таких условиях лучше ничего не выставлять наружу.
Если вам нужно обмениваться с сайтом или сторонним сервисом, есть хорошие средства, я про них в докладе уже упоминал.
А есть какие-то готовые инструменты для защиты базы от внешнего доступа? Какими сервисами можно воспользоваться 1С-нику?
Очень многие используют nginx, это хорошее программное обеспечение, его можно использовать как реверсное прокси для балансировки и фильтрации запросов.
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Безопасность в 1С". Больше статей можно прочитать здесь.
Читайте также: