Предновогодняя админская суета
Уже совсем скоро новогодние праздники и уже сегодня пора начинать к ним готовиться. Но у админа подготовка к праздникам – это не салаты и мандарины, а совсем-совсем иные вещи.
Чем отличаются новогодние праздники от иных? Не только длительными каникулами, но и практически резким снижением всякой рабочей активности. Закрыты представительства, сервисы, гарантийки. Не работают банки, не производятся поставки и отгрузки, в поддержке остается только первая линия.
По сути, вся страна уходит на каникулы и остается только розничный сектор, где можно купить выпить и закусить, ну и мышку с клавиатурой, если вы их неосторожно залили шампанским. Не более.
Поэтому, если вы не хотите омрачить праздник себе и своим коллегам, а тем более руководству – заведите за правило вводить мораторий на изменения хотя бы за неделю до Нового года.
Почему? А чтобы успеть собрать обратную связь и выявить все косяки или даже успеть выполнить откат до праздников.
Поработать на новогодних каникулах – тоже плохая идея. Потому что кроме вас и вашего желания есть еще внешний фактор и если он вдруг выстрелит, то вы останетесь с ним один на один, и никто вам не сможет помочь до конца праздников или как минимум до первого условно рабочего дня.
Какие это могут быть факторы? Да элементарно, слетела лицензия, закончилась подписка и т.д. и т.п.
Один мой коллега так влип на одной отраслевой. Взял и обновил на праздниках, а релиз возьми ему и скажи, что обновляться на него он не имел права, так как закончилась подписка на обновления.
Подписка действительно закончилась, только вот оплатить ее до десятых чисел не было никакой возможности, банки на отдыхе, безналичный расчет не работает. Хорошо, что были бекапы.
И, как ясно показал приведенный мною случай, внимательно изучите сроки окончания договоров, подписок, сертификатов, доменных имен и т.д. и т.п. Т.е. всего, что имеет свойство заканчиваться и оплатите их заранее.
Не забудьте проверить и самовыпущенные сертификаты, скажем для VPN, они тоже имеют свойство заканчиваться и тоже внезапно.
Проверьте балансы на всех ваших договорах и заранее пополните их, потому что это классика жанра – закончившийся баланс на 4G модеме торговой точки, номера которой никто не знает, а кто знает уехал кататься на лыжах в ненаселенку и надолго пропал с радаров.
Заранее закупите расходные материалы и ЗИП, может он и не пригодится, но лучше пусть будет. Потому как в провинции, в каком-нибудь райцентре даже заправить картридж на праздниках может быть целой проблемой, поэтому пусть будет еще один – новый.
Напишите подробные инструкции всему рядовому персоналу, который остается дежурить по возможным проблемам и способам их решения, или хотя бы временным обходным схемам. Ведь беда может приключиться, когда вы едете в поезде или летите в самолете и недоступны для связи.
Кроме того, обязательно позаботьтесь о наличии доступов, как виртуальных, так и физических. В нашей практике уже были случаи, когда проблемы возникали тупо в отсутствии нужных ключей и недоступности сотрудников, могущих дать указание выдать ключи или комиссией войти в кабинет руководителя и взять там дубликат.
Т.е. должен быть четкий регламент, как и кто может на праздниках получить ключи от серверной или склада ЗИП. А также у кого будут все явки и пароли, мало ли что может случиться.
В общем, как видим, задач перед праздниками много, но закончим с того, с чего начали – не вносите изменений. Введите на них мораторий.
Уже совсем скоро новогодние праздники и уже сегодня пора начинать к ним готовиться. Но у админа подготовка к праздникам – это не салаты и мандарины, а совсем-совсем иные вещи.
Чем отличаются новогодние праздники от иных? Не только длительными каникулами, но и практически резким снижением всякой рабочей активности. Закрыты представительства, сервисы, гарантийки. Не работают банки, не производятся поставки и отгрузки, в поддержке остается только первая линия.
По сути, вся страна уходит на каникулы и остается только розничный сектор, где можно купить выпить и закусить, ну и мышку с клавиатурой, если вы их неосторожно залили шампанским. Не более.
Поэтому, если вы не хотите омрачить праздник себе и своим коллегам, а тем более руководству – заведите за правило вводить мораторий на изменения хотя бы за неделю до Нового года.
Почему? А чтобы успеть собрать обратную связь и выявить все косяки или даже успеть выполнить откат до праздников.
Поработать на новогодних каникулах – тоже плохая идея. Потому что кроме вас и вашего желания есть еще внешний фактор и если он вдруг выстрелит, то вы останетесь с ним один на один, и никто вам не сможет помочь до конца праздников или как минимум до первого условно рабочего дня.
Какие это могут быть факторы? Да элементарно, слетела лицензия, закончилась подписка и т.д. и т.п.
Один мой коллега так влип на одной отраслевой. Взял и обновил на праздниках, а релиз возьми ему и скажи, что обновляться на него он не имел права, так как закончилась подписка на обновления.
Подписка действительно закончилась, только вот оплатить ее до десятых чисел не было никакой возможности, банки на отдыхе, безналичный расчет не работает. Хорошо, что были бекапы.
И, как ясно показал приведенный мною случай, внимательно изучите сроки окончания договоров, подписок, сертификатов, доменных имен и т.д. и т.п. Т.е. всего, что имеет свойство заканчиваться и оплатите их заранее.
Не забудьте проверить и самовыпущенные сертификаты, скажем для VPN, они тоже имеют свойство заканчиваться и тоже внезапно.
Проверьте балансы на всех ваших договорах и заранее пополните их, потому что это классика жанра – закончившийся баланс на 4G модеме торговой точки, номера которой никто не знает, а кто знает уехал кататься на лыжах в ненаселенку и надолго пропал с радаров.
Заранее закупите расходные материалы и ЗИП, может он и не пригодится, но лучше пусть будет. Потому как в провинции, в каком-нибудь райцентре даже заправить картридж на праздниках может быть целой проблемой, поэтому пусть будет еще один – новый.
Напишите подробные инструкции всему рядовому персоналу, который остается дежурить по возможным проблемам и способам их решения, или хотя бы временным обходным схемам. Ведь беда может приключиться, когда вы едете в поезде или летите в самолете и недоступны для связи.
Кроме того, обязательно позаботьтесь о наличии доступов, как виртуальных, так и физических. В нашей практике уже были случаи, когда проблемы возникали тупо в отсутствии нужных ключей и недоступности сотрудников, могущих дать указание выдать ключи или комиссией войти в кабинет руководителя и взять там дубликат.
Т.е. должен быть четкий регламент, как и кто может на праздниках получить ключи от серверной или склада ЗИП. А также у кого будут все явки и пароли, мало ли что может случиться.
В общем, как видим, задач перед праздниками много, но закончим с того, с чего начали – не вносите изменений. Введите на них мораторий.
👍64💯5
Имеется следующая конфигурация WireGuard:
Первые два пира объединяют сеть офиса и филиалов, они работают. Нижние два пира предназначены для подключения ноутбуков руководителя и главного бухгалтера.
Но почему-то работает только один из них, рандомным образом. И если подключается второй, то тут же выбивает первого.
В чем причина?
/interface wireguard peers
add allowed-address=10.10.10.0/24,192.168.1.0/24 interface=wireguard1 name=Site1
add allowed-address=10.10.10.0/24,192.168.3.0/24 interface=wireguard1 name=Site2
add allowed-address=10.10.10.0/24 interface=wireguard1 name=Director_Notebook
add allowed-address=10.10.10.0/24 interface=wireguard1 name=Buh_Notebook
Первые два пира объединяют сеть офиса и филиалов, они работают. Нижние два пира предназначены для подключения ноутбуков руководителя и главного бухгалтера.
Но почему-то работает только один из них, рандомным образом. И если подключается второй, то тут же выбивает первого.
В чем причина?
🤔6🥱3👍1
В чем причина нестабильной работы WireGuard?
Anonymous Quiz
14%
Пересекается внутренная адресация сетей на ноутбуках
10%
Нельзя на одном Wireguard соединении сочетать site-to-site и удаленных пользователей
12%
Нужен отдельный WireGuard интерфейс каждому пользователю
9%
Не указан диапазон разрешенных IP для сетей ноутбуков
30%
Нужно заменить 10.10.10.0/24 на 10.10.10.х/32
2%
Нужно обновить прошивку RouterOS, это баг
5%
Недостаточно данных для правильного ответа
7%
Где-то совпадают публичные ключи
8%
Оба клиента работают из-за одного NAT
3%
В конфигурации все верно, нужно искать внешний фактор
👍12👎3🤯2
⚠️ Киберугрозы не ждут! Готовы защитить свой бизнес и свою личную безопасность, оставаясь на шаг впереди?
Добро пожаловать в «ИБ inform» — ваш надежный источник знаний и инструментов для кибербезопасности! Меня зовут Сергей Михайлюк, я CISO с многолетним опытом, и на этом канале делюсь секретами защиты, которые действительно работают.
🔐 Зачем подписываться?
- Эксклюзивные новости и аналитика: Узнайте первыми о важных инцидентах и трендах.
- Лайфхаки, которые усиливают защиту: Практические советы для бизнеса и личной безопасности.
- Реальные кейсы и решения: Только проверенные методы и инсайты из моего опыта работы.
- Сообщество единомышленников: Присоединяйтесь к комьюнити, где вы сможете обмениваться опытом.
⚙️ ИБ inform — это не просто канал, это ваше конкурентное преимущество в мире информационной безопасности.
Добро пожаловать в «ИБ inform» — ваш надежный источник знаний и инструментов для кибербезопасности! Меня зовут Сергей Михайлюк, я CISO с многолетним опытом, и на этом канале делюсь секретами защиты, которые действительно работают.
🔐 Зачем подписываться?
- Эксклюзивные новости и аналитика: Узнайте первыми о важных инцидентах и трендах.
- Лайфхаки, которые усиливают защиту: Практические советы для бизнеса и личной безопасности.
- Реальные кейсы и решения: Только проверенные методы и инсайты из моего опыта работы.
- Сообщество единомышленников: Присоединяйтесь к комьюнити, где вы сможете обмениваться опытом.
⚙️ ИБ inform — это не просто канал, это ваше конкурентное преимущество в мире информационной безопасности.
👍4🤮3👌2👏1
Все-таки 1С образумилась и не стала совершать смелых экспериментов на платформе 8.3.27, но выпустила новую версию 8.5, с одноименным новым интерфейсом.
С фантазией там ожидаемо туго, поэтому интерфейс так и называется «версия 8.5». Посмотреть на него можно на скриншотах и заодно сравнить сколько информации помещалось в окно одного и того же размера на Такси и на новом 8.5.
Конечно, если развернуть окно на 2K или 4К монитор, то будет нормально, но рабочими лошадками были и еще долго будут оставаться FHD мониторы, а там все плохо. Интерфейс неоправданно переукрупнен, много ненужных отступов и свободного места.
При том, что это не софт для домохозяек с двумя большими кнопками и котиками, а серьезное рабочее ПО для профессионалов, в котором они проводят большую часть рабочего дня.
Ах, да… Еще темную тему завезли…
С фантазией там ожидаемо туго, поэтому интерфейс так и называется «версия 8.5». Посмотреть на него можно на скриншотах и заодно сравнить сколько информации помещалось в окно одного и того же размера на Такси и на новом 8.5.
Конечно, если развернуть окно на 2K или 4К монитор, то будет нормально, но рабочими лошадками были и еще долго будут оставаться FHD мониторы, а там все плохо. Интерфейс неоправданно переукрупнен, много ненужных отступов и свободного места.
При том, что это не софт для домохозяек с двумя большими кнопками и котиками, а серьезное рабочее ПО для профессионалов, в котором они проводят большую часть рабочего дня.
Ах, да… Еще темную тему завезли…
🤯28🤮20😁5👍2👎2
Allowed IPs в Wireguard
Большинство ответивших на наш вчерашний вопрос ответили правильно, дело действительно в Allowed IPs.
Давайте разберемся, что это за зверь такой и с чем его едят. Сразу скажем, многие ошибочно путают его с маршрутизацией, но к маршрутизации, как процессу поиска маршрутизатором интерфейса выхода он не имеет никакого отношения.
Хотя некоторые реализации клиента WireGuard, например, для Windows, добавляют в систему маршруты на основе представленной в Allowed IPs информации.
На самом деле механизм Allowed IPs ближе к политикам IPsec и определяют какой трафик на основании адресов источника и назначения должен быть зашифрован и отправлен пиру.
При помощи самой обычной маршрутизации мы можем завернуть на WireGuard интерфейс любой трафик, но пирам пойдет только тот, который попадает под Allowed IPs.
Этот процесс называется криптографической маршрутизацией и в конечном итоге определяет, каким именно ключом будет зашифрован этот трафик и какому пиру он отправится.
Еще раз повторим, что не стоит путать его с маршрутизацией обычной, так как криптографическая маршрутизация начинает работать уже после того, как система приняла решение о маршрутизации и отправила трафик на WireGuard интерфейс.
А теперь вернемся к нашим баранам и сначала посмотрим, почему работает Site-to-Site. Там все просто, адреса источника-назначения принадлежат сетям 192.168.x.x и спокойно обрабатываются криптографической маршрутизацией.
Другое дело, когда клиент непосредственно установлен на конечное устройство, в таком случае адрес источника-назначения будет из диапазона внутренних адресов WireGuard, т.е. 10.10.10.x в нашем случае.
А вот тут уже беда, WireGuard получает пакет, скажем, для 10.10.10.5 и недоумевает что с ним делать. Куда его деть – понятно, можно разослать всем пирам, если у каждого указано 10.10.10.0/24, это не проблема.
Проблема в том, каким ключом его зашифровать и судя по эффекту вопрос этот решается рандомно. Если вам повезло, то нужный пир расшифрует этот пакет и все будет работать, не повезло – пакет придет зашифрованный чужим ключом и будет отброшен.
При этом сам WG будет показывать нам, что соединение установлено и рукопожатие пройдено. И это действительно так. Никто же не виноват, что трафик, посылаемый пиру зашифрован другим ключом.
Кстати, подобная ерунда будет и, если мы попробуем пропигновать другой конец WG туннеля с роутера для Site-to-Site, с большой долей вероятности нам это не удастся, хотя трафик между узлами сетей будет ходить нормально. Причины те же самые, криптографическая маршрутизация не понимает какой именно ключ использовать для шифрования.
Большинство ответивших на наш вчерашний вопрос ответили правильно, дело действительно в Allowed IPs.
Давайте разберемся, что это за зверь такой и с чем его едят. Сразу скажем, многие ошибочно путают его с маршрутизацией, но к маршрутизации, как процессу поиска маршрутизатором интерфейса выхода он не имеет никакого отношения.
Хотя некоторые реализации клиента WireGuard, например, для Windows, добавляют в систему маршруты на основе представленной в Allowed IPs информации.
На самом деле механизм Allowed IPs ближе к политикам IPsec и определяют какой трафик на основании адресов источника и назначения должен быть зашифрован и отправлен пиру.
При помощи самой обычной маршрутизации мы можем завернуть на WireGuard интерфейс любой трафик, но пирам пойдет только тот, который попадает под Allowed IPs.
Этот процесс называется криптографической маршрутизацией и в конечном итоге определяет, каким именно ключом будет зашифрован этот трафик и какому пиру он отправится.
Еще раз повторим, что не стоит путать его с маршрутизацией обычной, так как криптографическая маршрутизация начинает работать уже после того, как система приняла решение о маршрутизации и отправила трафик на WireGuard интерфейс.
А теперь вернемся к нашим баранам и сначала посмотрим, почему работает Site-to-Site. Там все просто, адреса источника-назначения принадлежат сетям 192.168.x.x и спокойно обрабатываются криптографической маршрутизацией.
Другое дело, когда клиент непосредственно установлен на конечное устройство, в таком случае адрес источника-назначения будет из диапазона внутренних адресов WireGuard, т.е. 10.10.10.x в нашем случае.
А вот тут уже беда, WireGuard получает пакет, скажем, для 10.10.10.5 и недоумевает что с ним делать. Куда его деть – понятно, можно разослать всем пирам, если у каждого указано 10.10.10.0/24, это не проблема.
Проблема в том, каким ключом его зашифровать и судя по эффекту вопрос этот решается рандомно. Если вам повезло, то нужный пир расшифрует этот пакет и все будет работать, не повезло – пакет придет зашифрованный чужим ключом и будет отброшен.
При этом сам WG будет показывать нам, что соединение установлено и рукопожатие пройдено. И это действительно так. Никто же не виноват, что трафик, посылаемый пиру зашифрован другим ключом.
Кстати, подобная ерунда будет и, если мы попробуем пропигновать другой конец WG туннеля с роутера для Site-to-Site, с большой долей вероятности нам это не удастся, хотя трафик между узлами сетей будет ходить нормально. Причины те же самые, криптографическая маршрутизация не понимает какой именно ключ использовать для шифрования.
👍42🤯6
❗️Кибератаки на российские компании достигают полутора миллионов в год, и их число продолжает расти. Особый риск представляют системы видеоконференцсвязи, которые становятся целью хакеров.
Как обеспечить безопасность ваших переговоров?
🔒 Dion — платформа для видеосвязи, которая гарантирует защиту ваших данных. Благодаря передовым протоколам шифрования, Dion надежно защищает от взломов, утечек и кибератак, даже если вы используете публичные каналы связи.
Dion — это не просто безопасность, но и удобство:
✔️ Запись и хранение видеовстреч.
✔️ Персональные и групповые чаты.
✔️ ИИ-расшифровка видео в текст для быстрого анализа встреч.
Убедитесь сами: начните пользоваться Dion всего за 59 руб. в месяц.
[Перейти к платформе и начать защищенные переговоры]
#реклама
О рекламодателе
Как обеспечить безопасность ваших переговоров?
🔒 Dion — платформа для видеосвязи, которая гарантирует защиту ваших данных. Благодаря передовым протоколам шифрования, Dion надежно защищает от взломов, утечек и кибератак, даже если вы используете публичные каналы связи.
Dion — это не просто безопасность, но и удобство:
✔️ Запись и хранение видеовстреч.
✔️ Персональные и групповые чаты.
✔️ ИИ-расшифровка видео в текст для быстрого анализа встреч.
Убедитесь сами: начните пользоваться Dion всего за 59 руб. в месяц.
[Перейти к платформе и начать защищенные переговоры]
#реклама
О рекламодателе
🤮9
Последнее время задают довольно много вопросов по резервному копированию MS SQL Server и такая статья у нас есть. Она не новая, но там ничего не изменилось, ни в целом, ни в деталях.
Резервное копирование баз данных Microsoft SQL Server
Несмотря на то, что в наших предыдущих материалах мы уже касались вопроса резервного копирования баз Microsoft SQL Server, читательский отклик показал необходимость создания полноценного материала с более глубокой проработкой теоретической части.
Действительно, выполненные с упором на практические инструкции статьи позволяют быстро настроить резервное копирование, но не объясняют причины выбора тех или иных настроек. Постараемся исправить этот пробел.
https://interface31.ru/tech_it/2015/02/rezervnoe-kopirovanie-baz-dannyh-microsoft-sql-server.html
Резервное копирование баз данных Microsoft SQL Server
Несмотря на то, что в наших предыдущих материалах мы уже касались вопроса резервного копирования баз Microsoft SQL Server, читательский отклик показал необходимость создания полноценного материала с более глубокой проработкой теоретической части.
Действительно, выполненные с упором на практические инструкции статьи позволяют быстро настроить резервное копирование, но не объясняют причины выбора тех или иных настроек. Постараемся исправить этот пробел.
https://interface31.ru/tech_it/2015/02/rezervnoe-kopirovanie-baz-dannyh-microsoft-sql-server.html
👍36
Стандартные расположения данных
Иерархия файловых систем основных ОС предполагают различную структуру хранения данных и одной из частей этой структуры является пользовательская папка. В Linux и UNIX-подобных системах это /home, в Windows - C:\Users.
Предполагается, что пользователь будет хранить свои данные именно там и не будет их располагать в местах откровенно нестандартных и, тем более, странных.
Только вот есть интересная особенность. В Linux или той же macOS данное правило строго соблюдается, может быть потому, что сами системы не сильно располагают к разбрасыванию пользователем своих данных куда попало.
Причем делают это самым простым и очевидным способом – прав на запись куда-либо за пределы домашней директории у пользователя нет. И ни у кого это не вызывает ни неприятия, ни отторжения.
При этом те же самые люди в Windows как будто специально стараются нарушать соглашение о хранении данных, размещая их буквально где попало.
Отчасти в этом есть вина самой системы, так как в Windows нет общей иерархии файловой системы, то люди привыкли хранить свои данные на дополнительных логических томах (D:, E: т.д.) и делать это так, как удобно им.
Очень часто эта практика сохраняется и в том случае, когда логический том один. Такое чаще всего бывает на ноутбуках или моноблоках, а разбивать на разделы единственный быстрый SSD размером в 250-500 ГБ не имеет смысла.
И вот вместо того, чтобы сложить все в папку пользователя и не париться то тут, то там, чаще всего в корне диска возникают различные пользовательские папки то с играми, то с документами, то с базами 1С (последние почему-то очень не любят размещать в тех же Документах, куда, кстати, сама 1С предлагает по умолчанию).
Что в этом плохого, спросите вы? В ответ я расскажу вам одну поучительную историю.
Третьего дня у одного моего знакомого что-то случилось с системой, то ли сделали что-то не так, то ли скачали что-то не то, но загружаться она перестала.
Ноутбук хороший, брендовый, HP. После пары неудачных загрузок он предложил ему восстановить систему и запустил утилиту Recovery Manager, которая предложила ему восстановление с сохранением программ и данных.
Он внимательно прочитал текст на экране, вставил внешний диск для сохранения данных и запустил процесс. Некоторое время просто наблюдал и, убедившись, что утилита реально сохраняет на внешний диск данные пошел пить чай, оставив ноутбук восстанавливаться.
Через пару часов все было готово, программы на месте, документы на месте, все работает. Но если все идет хорошо – значит вы чего-то не заметили.
Это чего-то заметила на следующий день его жена. Когда запустила 1С, а та ей бодро сообщила, что информационная база не обнаружена.
Как вы уже догадались, лежала база не в профиле пользователя, а в C:\1CBases или чем-то подобным.
Изучив то, что утилита сохранила на внешний диск, выяснилось, что туда попали папки Windows, Program Files, Program Data и т.д. для восстановления программ и полностью паки пользователей из C:\Users.
Более никаких папок туда не копировалось, да и, наверное, никогда не предполагалось, потому что разработчики утилиты исходили из того, что и данные, и программы у пользователя будут в стандартных расположениях.
Бекапов, как полагается, не было. Спасло то, что недавно эту базу выгружали на флешку, чтобы передать внешнему бухгалтеру. Так что отделались почти легким испугом, ну и за месяц документы заново руками вбить.
А ведь все могло быть гораздо хуже. Поэтому храните данные в стандартных расположениях, ну и не забывайте про бекапы.
Иерархия файловых систем основных ОС предполагают различную структуру хранения данных и одной из частей этой структуры является пользовательская папка. В Linux и UNIX-подобных системах это /home, в Windows - C:\Users.
Предполагается, что пользователь будет хранить свои данные именно там и не будет их располагать в местах откровенно нестандартных и, тем более, странных.
Только вот есть интересная особенность. В Linux или той же macOS данное правило строго соблюдается, может быть потому, что сами системы не сильно располагают к разбрасыванию пользователем своих данных куда попало.
Причем делают это самым простым и очевидным способом – прав на запись куда-либо за пределы домашней директории у пользователя нет. И ни у кого это не вызывает ни неприятия, ни отторжения.
При этом те же самые люди в Windows как будто специально стараются нарушать соглашение о хранении данных, размещая их буквально где попало.
Отчасти в этом есть вина самой системы, так как в Windows нет общей иерархии файловой системы, то люди привыкли хранить свои данные на дополнительных логических томах (D:, E: т.д.) и делать это так, как удобно им.
Очень часто эта практика сохраняется и в том случае, когда логический том один. Такое чаще всего бывает на ноутбуках или моноблоках, а разбивать на разделы единственный быстрый SSD размером в 250-500 ГБ не имеет смысла.
И вот вместо того, чтобы сложить все в папку пользователя и не париться то тут, то там, чаще всего в корне диска возникают различные пользовательские папки то с играми, то с документами, то с базами 1С (последние почему-то очень не любят размещать в тех же Документах, куда, кстати, сама 1С предлагает по умолчанию).
Что в этом плохого, спросите вы? В ответ я расскажу вам одну поучительную историю.
Третьего дня у одного моего знакомого что-то случилось с системой, то ли сделали что-то не так, то ли скачали что-то не то, но загружаться она перестала.
Ноутбук хороший, брендовый, HP. После пары неудачных загрузок он предложил ему восстановить систему и запустил утилиту Recovery Manager, которая предложила ему восстановление с сохранением программ и данных.
Он внимательно прочитал текст на экране, вставил внешний диск для сохранения данных и запустил процесс. Некоторое время просто наблюдал и, убедившись, что утилита реально сохраняет на внешний диск данные пошел пить чай, оставив ноутбук восстанавливаться.
Через пару часов все было готово, программы на месте, документы на месте, все работает. Но если все идет хорошо – значит вы чего-то не заметили.
Это чего-то заметила на следующий день его жена. Когда запустила 1С, а та ей бодро сообщила, что информационная база не обнаружена.
Как вы уже догадались, лежала база не в профиле пользователя, а в C:\1CBases или чем-то подобным.
Изучив то, что утилита сохранила на внешний диск, выяснилось, что туда попали папки Windows, Program Files, Program Data и т.д. для восстановления программ и полностью паки пользователей из C:\Users.
Более никаких папок туда не копировалось, да и, наверное, никогда не предполагалось, потому что разработчики утилиты исходили из того, что и данные, и программы у пользователя будут в стандартных расположениях.
Бекапов, как полагается, не было. Спасло то, что недавно эту базу выгружали на флешку, чтобы передать внешнему бухгалтеру. Так что отделались почти легким испугом, ну и за месяц документы заново руками вбить.
А ведь все могло быть гораздо хуже. Поэтому храните данные в стандартных расположениях, ну и не забывайте про бекапы.
👍44👎5😁1
Устали от ограничений и долгой настройки серверов? HSVDS поможет в работе!
Мы предлагаем быстрые VDS для разработчиков с безлимитным интернетом и удобной панелью управления.
А чтобы вы могли начать максимально быстро, мы подготовили предустановленный образ GitLab:
✅ Управление репозиториями кода для Git
✅ Система отслеживания задач
✅ Удобная Wiki для документации
✅ Мощный CI/CD пайплайн
✅ И многое другое для продуктивной работы всей команды!
HSVDS — это стабильность, готовые решения и свобода для ваших идей 💻
Мы предлагаем быстрые VDS для разработчиков с безлимитным интернетом и удобной панелью управления.
А чтобы вы могли начать максимально быстро, мы подготовили предустановленный образ GitLab:
✅ Управление репозиториями кода для Git
✅ Система отслеживания задач
✅ Удобная Wiki для документации
✅ Мощный CI/CD пайплайн
✅ И многое другое для продуктивной работы всей команды!
HSVDS — это стабильность, готовые решения и свобода для ваших идей 💻
👍2❤1👌1👀1
Спрашивали вчера:
SSH-туннели на службе системного администратора
Любому системному администратору приходится постоянно работать удаленно, но случаются ситуации, когда нужно срочно подключиться к узлам внутренней сети, доступ к которым снаружи закрыт.
Хорошо если есть доступ на другие узлы данной сети, но бывает, что доступа из глобальной сети нет вообще, в этих случаях обычно используют TeamViewer или аналогичное ПО, но если к такой сети есть возможность подключиться через SSH или установить соединение с промежуточным SSH-сервером, то можно быстро и просто организовать доступ без привлечения стороннего ПО.
https://interface31.ru/tech_it/2017/04/ssh-tunneli-na-sluzhbe-sistemnogo-administratora.html
SSH-туннели на службе системного администратора
Любому системному администратору приходится постоянно работать удаленно, но случаются ситуации, когда нужно срочно подключиться к узлам внутренней сети, доступ к которым снаружи закрыт.
Хорошо если есть доступ на другие узлы данной сети, но бывает, что доступа из глобальной сети нет вообще, в этих случаях обычно используют TeamViewer или аналогичное ПО, но если к такой сети есть возможность подключиться через SSH или установить соединение с промежуточным SSH-сервером, то можно быстро и просто организовать доступ без привлечения стороннего ПО.
https://interface31.ru/tech_it/2017/04/ssh-tunneli-na-sluzhbe-sistemnogo-administratora.html
👍35❤2
Клиент-серверная 1С. Структура
Вопросы и отзывы показывают, что многие коллеги слабо представляют себе устройство клиент-серверной 1С и взаимодействие между ее компонентами.
Начнем с сервера, он так и называется Сервер 1С:Предприятие и может работать как под Windows, так и в Linux. Рабочая инсталляция сервера называется Кластер серверов 1С, даже если экземпляр сервера один.
Впоследствии, для увеличения производительности, мы можем добавлять в кластер дополнительные рабочие сервера, и менеджер кластера будет распределять между ними нагрузку.
Также мы можем выносить на отдельные рабочие сервера дополнительные функции, например, сервер лицензирования.
Вся информация, с которой работает пользователь, а также код конфигурации (прикладного решения) хранятся в СУБД, в качестве которых чаще всего используется MS SQL или PostgreSQL.
Сразу хочется обратить внимание на то, что с СУБД взаимодействует исключительно сервер, клиенты доступа к серверу СУБД не имеют и напрямую в БД не обращаются. Более того, это прямо запрещено лицензионным соглашением 1С.
Вся информация из одной информационной базы 1С, включая конфигурацию, загруженные в нее отчеты, обработки и расширения хранится в одной базе данных СУБД. Т.е. вы можете выполнять полноценное копирование средствами СУБД и затем восстанавливать ИБ подобным образом.
Однако если вы лицензируете СУБД по количеству пользователей, то вам потребуется количество лицензий по числу реальных клиентских подключений.
Теперь перейдем к клиентам. Толстый клиент является устаревшим и современными конфигурациями не используется.
Его неприятной особенностью является то, что он все данные обрабатывает самостоятельно и сервер в этом случае будет для него просто посредником, который извлекает данные из СУБД, передает их клиенту и получив назад снова помещает в БД.
Для работы в таком режиме требуются широкие каналы и мощная рабочая станция, на которой запущен толстый клиент.
Сейчас в режиме толстого клиента работает только конфигуратор, но в эксплуатации еще могут быть устаревшие конфигурации на обычных формах, которые не умеют работать в ином режиме.
Основной вариант работы для современных конфигураций – это тонкий клиент. В этом случае задачи по извлечению и обработке данных ложатся на сервер, а клиент принимает только ввод пользователя и показывает ему результаты вычислений.
В дополнение к этому тонкий клиент самостоятельно обрабатывает введенные данные и выполняет простейшие вычисления, ради которых нет смысла обращаться к серверу. Например, пользователь изменил колонку цена, после чего тонкий клиент сам пересчитает колонку сумма.
Но любые действия по получению данных из СУБД и помещению их туда выполняет сервер, равно как и все основные тяжелые вычисления.
Благодаря этому тонкий клиент отлично работает даже на медленных каналах, включая мобильный интернет.
Он может подключаться к кластеру серверов как непосредственно, так и через веб-сервер. В серверном режиме веб-сервер просто проксирует запросы от тонкого клиента к кластеру серверов и непосредственных вычислений не производит.
Такой режим удобен для публикации баз наружу, в этом случае достаточно одного порта, который можно защитить SSL сертификатом и дополнительной парольной защитой.
Ну и наконец веб-клиент, работает в браузере и, по сути, мало чем отличается от тонкого клиента. Но в этом случае клиентом кластера серверов становится модуль веб-сервера и вся клиентская нагрузка ложиться на него, но она как правило невелика и особых проблем не составляет.
Единственной проблемой может стать выделение оперативной памяти, потому что после отключения веб-клиента его сеанс, а следовательно, и выделенная ему память, сохраняются в течении 20 минут.
Также веб-клиенту присущ ряд ограничений, а также у него своя схема лицензирования, поэтому использовать веб-клиент следует только тогда, когда использовать тонкий клиент невозможно.
Поэтому, проектируя соверменные схемы работы с 1С всегда исходите из использования тонкого клиента.
Вопросы и отзывы показывают, что многие коллеги слабо представляют себе устройство клиент-серверной 1С и взаимодействие между ее компонентами.
Начнем с сервера, он так и называется Сервер 1С:Предприятие и может работать как под Windows, так и в Linux. Рабочая инсталляция сервера называется Кластер серверов 1С, даже если экземпляр сервера один.
Впоследствии, для увеличения производительности, мы можем добавлять в кластер дополнительные рабочие сервера, и менеджер кластера будет распределять между ними нагрузку.
Также мы можем выносить на отдельные рабочие сервера дополнительные функции, например, сервер лицензирования.
Вся информация, с которой работает пользователь, а также код конфигурации (прикладного решения) хранятся в СУБД, в качестве которых чаще всего используется MS SQL или PostgreSQL.
Сразу хочется обратить внимание на то, что с СУБД взаимодействует исключительно сервер, клиенты доступа к серверу СУБД не имеют и напрямую в БД не обращаются. Более того, это прямо запрещено лицензионным соглашением 1С.
Вся информация из одной информационной базы 1С, включая конфигурацию, загруженные в нее отчеты, обработки и расширения хранится в одной базе данных СУБД. Т.е. вы можете выполнять полноценное копирование средствами СУБД и затем восстанавливать ИБ подобным образом.
Однако если вы лицензируете СУБД по количеству пользователей, то вам потребуется количество лицензий по числу реальных клиентских подключений.
Теперь перейдем к клиентам. Толстый клиент является устаревшим и современными конфигурациями не используется.
Его неприятной особенностью является то, что он все данные обрабатывает самостоятельно и сервер в этом случае будет для него просто посредником, который извлекает данные из СУБД, передает их клиенту и получив назад снова помещает в БД.
Для работы в таком режиме требуются широкие каналы и мощная рабочая станция, на которой запущен толстый клиент.
Сейчас в режиме толстого клиента работает только конфигуратор, но в эксплуатации еще могут быть устаревшие конфигурации на обычных формах, которые не умеют работать в ином режиме.
Основной вариант работы для современных конфигураций – это тонкий клиент. В этом случае задачи по извлечению и обработке данных ложатся на сервер, а клиент принимает только ввод пользователя и показывает ему результаты вычислений.
В дополнение к этому тонкий клиент самостоятельно обрабатывает введенные данные и выполняет простейшие вычисления, ради которых нет смысла обращаться к серверу. Например, пользователь изменил колонку цена, после чего тонкий клиент сам пересчитает колонку сумма.
Но любые действия по получению данных из СУБД и помещению их туда выполняет сервер, равно как и все основные тяжелые вычисления.
Благодаря этому тонкий клиент отлично работает даже на медленных каналах, включая мобильный интернет.
Он может подключаться к кластеру серверов как непосредственно, так и через веб-сервер. В серверном режиме веб-сервер просто проксирует запросы от тонкого клиента к кластеру серверов и непосредственных вычислений не производит.
Такой режим удобен для публикации баз наружу, в этом случае достаточно одного порта, который можно защитить SSL сертификатом и дополнительной парольной защитой.
Ну и наконец веб-клиент, работает в браузере и, по сути, мало чем отличается от тонкого клиента. Но в этом случае клиентом кластера серверов становится модуль веб-сервера и вся клиентская нагрузка ложиться на него, но она как правило невелика и особых проблем не составляет.
Единственной проблемой может стать выделение оперативной памяти, потому что после отключения веб-клиента его сеанс, а следовательно, и выделенная ему память, сохраняются в течении 20 минут.
Также веб-клиенту присущ ряд ограничений, а также у него своя схема лицензирования, поэтому использовать веб-клиент следует только тогда, когда использовать тонкий клиент невозможно.
Поэтому, проектируя соверменные схемы работы с 1С всегда исходите из использования тонкого клиента.
👍56👎3❤1🤔1
Хватит выполнять скучную рутину руками ✋
Ansible придумали, чтобы вы вместо возни с однотипными задачами по настройке конфигов:
✅ писали плейбуки и роли,
✅ деплоили Flask-приложения,
✅ настраивали IaC в Gitlab,
✅ автоматизировали процесс управления IT-инфраструктурой,
✅ наводили в ней порядок.
Для всех, кто только начинает свой путь, мы подготовили бесплатный чек-лист по основам Ansible. Он поможет сформировать необходимые навыки для решения реальных задач в короткий срок.
А если вы уже знакомы с Ansible, чек-лист тоже будет полезен — для самопроверки и подготовки к собеседованиям, ведь эти умения точно будут в требованиях к вакансиям 👌
👉 Забрать чек-лист можно бесплатно прямо сейчас в боте.
erid: 2W5zFHVe1oE
Ansible придумали, чтобы вы вместо возни с однотипными задачами по настройке конфигов:
✅ писали плейбуки и роли,
✅ деплоили Flask-приложения,
✅ настраивали IaC в Gitlab,
✅ автоматизировали процесс управления IT-инфраструктурой,
✅ наводили в ней порядок.
Для всех, кто только начинает свой путь, мы подготовили бесплатный чек-лист по основам Ansible. Он поможет сформировать необходимые навыки для решения реальных задач в короткий срок.
А если вы уже знакомы с Ansible, чек-лист тоже будет полезен — для самопроверки и подготовки к собеседованиям, ведь эти умения точно будут в требованиях к вакансиям 👌
👉 Забрать чек-лист можно бесплатно прямо сейчас в боте.
erid: 2W5zFHVe1oE
👍3
Даешь план!
Каждый раз при приближении новогодних праздников очень и очень многие как будто срываются с цепи и требуют непременно выполнить весь накопившийся объем задач непременно до Нового года.
Зачем? Да пес его знает. Видимо есть такая традиция, возможно, связанная с красивыми отчетами. Ну я еще понимаю, если подобное происходит в бюджетной сфере, но когда таким страдает бизнес, причем его топы, которые отчитываются только перед самими собой – то тут кроме недоумения выразить нечего.
Так и недавно, один наш заказчик, который силами стороннего подрядчика внедряет новую систему управления клиникой, а мы обеспечиваем интеграцию с 1С спросил, если подрядчик таки сдаст им сегодня систему, то сможем ли мы тоже сдать свой контур.
На что мы ответили, что конечно же нет. Почему? Да потому что имея в запасе половину рабочего дня нет никакой возможности все проверить и, при необходимости, исправить. И незачем.
А когда заказчик стал требовать и настаивать ему были заданы простые и логичные вопросы.
Первый. А для чего вам к Новому году интеграция с 1С? Ведь вся бухгалтерия в полном составе уходит на каникулы и выйдет только 9 января. Это «понедельник», который четверг, а впереди еще понедельник 13-е с его варениками и нормальная работа отдела начнется только со вторника 14-го.
И для кого надо сдать проект без нормальной проверки 28-го? И кто его с вашей стороны проверять будет? Бухгалтера, которые уже с обеда на низком старте и успели закинуться парой бокалов шампанского?
Но если сильно хотите, то мы сдадим, а вы подпишете и оплатите тоже 28-го. А все доработки потом по отдельному прайсу.
Как так по отдельному? А вот так. Вам же надо все сдать к Новому году, а нам не надо и вашей бухгалтерии тоже не надо. И вообще ей оно понадобится только к концу месяца января, так что времени там еще вагон и маленькая тележка.
Можно спокойно все проверить, доделать, доработать и сдать проект именно как надо, а не на отшибись, лишь бы успеть к срокам.
При этом руководство заказчика вроде бы все понимает, но вот что-то уперлись им эти даты и сроки.
А по факту сдача проекта 28-го не нужна никому, ни нам, как исполнителю, ни бухгалтерии клиента как заказчику. Потому что мы все понимаем, что при реальной эксплуатации сторонней системы, внедряемой третьими лицами, обязательно возникнут вопросы и различные ситуации.
И одно дело решать их в рамках открытого проекта, с оговоренными бюджетами и расценками. И совсем другое, если проект закрыт и сдан.
Даже при всем взаимопонимании и всем таком прочем все это надо будет хорошо обложить бумагами, потому что по факту от заказчика будет получена рекламация, что будет подразумевать, что наш проект не соответствует техзаданию и нам надо устранить недостатки за свой счет.
А тут просторное поле для всяких недопониманий и прочих нехороших последствий, причем в обе стороны.
Поэтому, если хотите потерять заказчика – сдайте ему сырой проект к красивой дате.
А можно не сдавать? Можно. Для этого, правда, нужно с самого начала нормально обложиться бумажками и отдельно описать в договоре порядок сдачи – приемки проекта. Причем так, чтобы представители заказчика действительно проверили все ключевые функции и письменно подтвердили, что все соответствует ТЗ.
Хотите проект 28-го? ОК, когда ваши подрядчики вам все сделают? Часам к 12-и? ОК, нам тоже час-полтора понадобиться. Потом мы вам передаем акт и к нему чек-лист на 10 страниц с указанием ответственных с вашей стороны.
Успеете все проверить, подписать и оплатить? Нет? А как же так? Ведь вы нас так торопили, ну тогда увидимся уже после праздников. Всего вам самого хорошего!
Такой подход отрезвляет и заставляет смотреть на вещи с рациональных позиций.
Кстати, в СССР при покупке дорогой техники всегда смотрели дату выпуска и если это был конец квартала или года, то ее не брали. Почему? Да потому что качество там было ниже плинтуса, так как все занимались именно тем, что «давали план».
Каждый раз при приближении новогодних праздников очень и очень многие как будто срываются с цепи и требуют непременно выполнить весь накопившийся объем задач непременно до Нового года.
Зачем? Да пес его знает. Видимо есть такая традиция, возможно, связанная с красивыми отчетами. Ну я еще понимаю, если подобное происходит в бюджетной сфере, но когда таким страдает бизнес, причем его топы, которые отчитываются только перед самими собой – то тут кроме недоумения выразить нечего.
Так и недавно, один наш заказчик, который силами стороннего подрядчика внедряет новую систему управления клиникой, а мы обеспечиваем интеграцию с 1С спросил, если подрядчик таки сдаст им сегодня систему, то сможем ли мы тоже сдать свой контур.
На что мы ответили, что конечно же нет. Почему? Да потому что имея в запасе половину рабочего дня нет никакой возможности все проверить и, при необходимости, исправить. И незачем.
А когда заказчик стал требовать и настаивать ему были заданы простые и логичные вопросы.
Первый. А для чего вам к Новому году интеграция с 1С? Ведь вся бухгалтерия в полном составе уходит на каникулы и выйдет только 9 января. Это «понедельник», который четверг, а впереди еще понедельник 13-е с его варениками и нормальная работа отдела начнется только со вторника 14-го.
И для кого надо сдать проект без нормальной проверки 28-го? И кто его с вашей стороны проверять будет? Бухгалтера, которые уже с обеда на низком старте и успели закинуться парой бокалов шампанского?
Но если сильно хотите, то мы сдадим, а вы подпишете и оплатите тоже 28-го. А все доработки потом по отдельному прайсу.
Как так по отдельному? А вот так. Вам же надо все сдать к Новому году, а нам не надо и вашей бухгалтерии тоже не надо. И вообще ей оно понадобится только к концу месяца января, так что времени там еще вагон и маленькая тележка.
Можно спокойно все проверить, доделать, доработать и сдать проект именно как надо, а не на отшибись, лишь бы успеть к срокам.
При этом руководство заказчика вроде бы все понимает, но вот что-то уперлись им эти даты и сроки.
А по факту сдача проекта 28-го не нужна никому, ни нам, как исполнителю, ни бухгалтерии клиента как заказчику. Потому что мы все понимаем, что при реальной эксплуатации сторонней системы, внедряемой третьими лицами, обязательно возникнут вопросы и различные ситуации.
И одно дело решать их в рамках открытого проекта, с оговоренными бюджетами и расценками. И совсем другое, если проект закрыт и сдан.
Даже при всем взаимопонимании и всем таком прочем все это надо будет хорошо обложить бумагами, потому что по факту от заказчика будет получена рекламация, что будет подразумевать, что наш проект не соответствует техзаданию и нам надо устранить недостатки за свой счет.
А тут просторное поле для всяких недопониманий и прочих нехороших последствий, причем в обе стороны.
Поэтому, если хотите потерять заказчика – сдайте ему сырой проект к красивой дате.
А можно не сдавать? Можно. Для этого, правда, нужно с самого начала нормально обложиться бумажками и отдельно описать в договоре порядок сдачи – приемки проекта. Причем так, чтобы представители заказчика действительно проверили все ключевые функции и письменно подтвердили, что все соответствует ТЗ.
Хотите проект 28-го? ОК, когда ваши подрядчики вам все сделают? Часам к 12-и? ОК, нам тоже час-полтора понадобиться. Потом мы вам передаем акт и к нему чек-лист на 10 страниц с указанием ответственных с вашей стороны.
Успеете все проверить, подписать и оплатить? Нет? А как же так? Ведь вы нас так торопили, ну тогда увидимся уже после праздников. Всего вам самого хорошего!
Такой подход отрезвляет и заставляет смотреть на вещи с рациональных позиций.
Кстати, в СССР при покупке дорогой техники всегда смотрели дату выпуска и если это был конец квартала или года, то ее не брали. Почему? Да потому что качество там было ниже плинтуса, так как все занимались именно тем, что «давали план».
👍50💯11❤1🔥1👏1
Несколько мыслей про "провал" импортозамещения
Сегодня в обсуждении поделились новостями, что не все хорошо с импортозамещением на объектах критической информационной инфраструктуры (КИИ), а точнее все нехорошо.
По разным оценкам пятая часть то ли только успела, то ли наоборот не успела. Но в любом случае импортозаместятся не все. И это, если честно, вполне ожидаемо.
Что такое КИИ? Это не контора на 10-20-100-500 рабочих мест с мальчиками и девочками менеджерами и какими-нибудь 1С и Битриксами. А критически важные объекты, требующие особой защиты, отказоустойчивости, способности выдерживать высокие нагрузки.
А что у нас для этого есть? Что-то есть, но все это в состоянии «ну вот, можете посмотреть, потрогать».
Никакого опыта серьезной эксплуатации таких систем нет, а следовательно, нет обратной связи, и даже сами разработчики не смогут сказать, как ведет себя их продукция под реальными нагрузками.
Если почитать более серьезную аналитику, а не там, где кричат, что все пропало, то можно найти следующие данные:
среди наиболее востребованного софта назывались межсетевые экраны (так ответили 54% респондентов), антивирусная защита (33%), сетевое оборудование (29%) и средства криптографической защиты (25%)
А также немаловажную роль играют и финансовые вопросы:
главной проблемой в процессе реализации проектов 27% опрошенных назвали подбор и закупку отечественного софта и оборудования. 14% опрошенных были вынуждены увеличить бюджет на информационную безопасность в десять раз
Если спокойно и непредвзято посмотреть на рынок импортозамещения, то реально мы импортозаместили пока уровень рабочей станции и базовых серверных приложений.
Даже если шагнуть чуть в сторону и попробовать заменить Active Directory, то уже окажется что там не все так просто и гладко, даже в гомогенной среде (допустим, везде только Linux.
Виртуализация? Ну более-менее, потому что просто имелась возможность пересобрать известные и проверенные решения с открытым кодом.
По сетям все не очень радостно, да, есть вендоры, есть продукты, но их еще доводить и доводить до ума. По-хорошему на это нужно несколько лет реальной эксплуатации на менее ответственных участках и несколько итераций продукта.
Вопрос по ценам тоже открыт, складывается впечатление что многие вендоры берут ее просто с потолка, по принципу проси много, а там можно и поторговаться. И если бюджет к этому не столь чувствителен, то бизнес привык считать деньги и задавать неудобные вопросы.
Ну и не стоит сбрасывать со счетов определенную категорию товарищей, которые, как всегда, ждали, что снова перенесут, передвинут и т.д. и т.п.
Ну а в целом участники этого процесса повели себя достаточно ожидаемо. Все-таки КИИ и одно дело сорвать процесс импортозамещения, а совсем другое уложить этот самый объект КИИ.
За первое грозят оргвыводами, но как там говорили молодые лейтенанты времен СССР: «Меньше взвода не дадут, дальше Кушки не пошлют».
А за уронить КИИ можно вполне реально и очень даже надолго присесть, причем не только заказчику, но и исполнителю.
Поэтому имеем то, что имеем. Хотя процесс худо-бедно идет и, по-хорошему, надо не подводить его под определенные даты, а стимулировать внедрение и эксплуатацию сначала в отраслях немного попроще, нежели КИИ.
Сегодня в обсуждении поделились новостями, что не все хорошо с импортозамещением на объектах критической информационной инфраструктуры (КИИ), а точнее все нехорошо.
По разным оценкам пятая часть то ли только успела, то ли наоборот не успела. Но в любом случае импортозаместятся не все. И это, если честно, вполне ожидаемо.
Что такое КИИ? Это не контора на 10-20-100-500 рабочих мест с мальчиками и девочками менеджерами и какими-нибудь 1С и Битриксами. А критически важные объекты, требующие особой защиты, отказоустойчивости, способности выдерживать высокие нагрузки.
А что у нас для этого есть? Что-то есть, но все это в состоянии «ну вот, можете посмотреть, потрогать».
Никакого опыта серьезной эксплуатации таких систем нет, а следовательно, нет обратной связи, и даже сами разработчики не смогут сказать, как ведет себя их продукция под реальными нагрузками.
Если почитать более серьезную аналитику, а не там, где кричат, что все пропало, то можно найти следующие данные:
среди наиболее востребованного софта назывались межсетевые экраны (так ответили 54% респондентов), антивирусная защита (33%), сетевое оборудование (29%) и средства криптографической защиты (25%)
А также немаловажную роль играют и финансовые вопросы:
главной проблемой в процессе реализации проектов 27% опрошенных назвали подбор и закупку отечественного софта и оборудования. 14% опрошенных были вынуждены увеличить бюджет на информационную безопасность в десять раз
Если спокойно и непредвзято посмотреть на рынок импортозамещения, то реально мы импортозаместили пока уровень рабочей станции и базовых серверных приложений.
Даже если шагнуть чуть в сторону и попробовать заменить Active Directory, то уже окажется что там не все так просто и гладко, даже в гомогенной среде (допустим, везде только Linux.
Виртуализация? Ну более-менее, потому что просто имелась возможность пересобрать известные и проверенные решения с открытым кодом.
По сетям все не очень радостно, да, есть вендоры, есть продукты, но их еще доводить и доводить до ума. По-хорошему на это нужно несколько лет реальной эксплуатации на менее ответственных участках и несколько итераций продукта.
Вопрос по ценам тоже открыт, складывается впечатление что многие вендоры берут ее просто с потолка, по принципу проси много, а там можно и поторговаться. И если бюджет к этому не столь чувствителен, то бизнес привык считать деньги и задавать неудобные вопросы.
Ну и не стоит сбрасывать со счетов определенную категорию товарищей, которые, как всегда, ждали, что снова перенесут, передвинут и т.д. и т.п.
Ну а в целом участники этого процесса повели себя достаточно ожидаемо. Все-таки КИИ и одно дело сорвать процесс импортозамещения, а совсем другое уложить этот самый объект КИИ.
За первое грозят оргвыводами, но как там говорили молодые лейтенанты времен СССР: «Меньше взвода не дадут, дальше Кушки не пошлют».
А за уронить КИИ можно вполне реально и очень даже надолго присесть, причем не только заказчику, но и исполнителю.
Поэтому имеем то, что имеем. Хотя процесс худо-бедно идет и, по-хорошему, надо не подводить его под определенные даты, а стимулировать внедрение и эксплуатацию сначала в отраслях немного попроще, нежели КИИ.
👍30💯14🥱1🤣1