В больших компаниях с развитой инфраструктурой и достаточными ресурсами, вполне соглашусь - там именно таким подходам и следуют. Хотя и так не без ложки дёгтя бывает - даже там не все и не везде умеют и готовы решать вопросы с наполнением тестовых стендов необходимыми для их корректной работы данными.
Ограничивать разработчиков в доступах на прод вполне логичный шаг и с этим массово в последние года все меньше проблем становится, но вот процессы создания тестовых стендов крайне желательно тщательно изучать. Обычно существуют довольно хорошо реализованные на стороне инфраструктуры мониторинги и контроли на доступы из тестовых сегментов в прод, но вот об обратном взаимодействии все ещё мало кто сходу задумывается.
Слияние всех описанных выше факторов может порождать, в какой-то момент, "интересные" открытия вида - тестовый стенд = реплика с прода 1-7-14-30 дневной давности. И хорошо ещё, если это по итогу быстро можно обнаружить в рамках каких-либо автоматизированных проверок тестовых сред, а не всплывает как-нибудь невзначай, либо вообще на инциденте.
К сожалению, как раз в более чем 95% случаях продукты 1С используются по прямому назначению и содержат все те самые выплаты/зарплаты и разнообразные ПДн сотрудников, клиентов, контрагентом.
Я бы тут даже расширил тогда, так как этот постулат, в конечном итоге, легко масштабируется и на любую иную систему. Самая безопасная эта та система, которая потушена, и к ней не имеют ни логического ни физического доступа никто, но само собой в реальности так нельзя сделать и вот тут уже и начинается борьба компромиссов удобства/работоспособности/безопасности.
При таких размерах компании, если бы их не было, было бы очень и очень больно. То, что описано в статье выше - собирательный образ основных узких мест, которые встречались при столкновении с продуктами 1С и процессами, построенными на них в разного размера и направленности бизнеса компаниях.
Смысл прост - представьте, что вы относительно новичок в ИБ, продукты 1С встречали тольк на слуху, пришли в новую компанию, а там вам говорят, что ценным активом для бизнеса являются продукты 1С и их хотелось бы проаудировать и привести в порядок.
А тут дьявол кроется в деталях - это стоимость только лицензий на 1 год или железа+внедрения+настройки+сопровождения+реагирования? Купить любой инструмент мало, надо уметь его внедрить в процессы, развивать и поддерживать потом. В случаях с малым и средним бизнесом, отпугивает не стоимость лицензий чаще, а то, какие накладные расходы это понесет за собой на дистанции.
Да и будем честны - DLP не панацея и любой из тех, кто плотно работал с этим классом продуктов, внедрял, решал проблемы и разгребал инциденты, писал исключения, может с уверенностью сказать, что обойти его не то чтобы невозможно. Само решение хорошее, но оно должно работать в комплексе с отстроенными процессами - классические подходы "всем все запретить" сейчас уже не пройдут.
В контексте больших проектов и крупных компаний я вполне согласен с вами - там действительно цель совсем не в урезании костов, а в ускорении сроков реализации проекта (в особенности, если своей необходимой экспертизы нет/мало, а растить ее долго).
Но не стоит тут забывать про формы сотрудничества типа ГПХ/СМЗ или небольших ИП - они вполне могут привлекаться для более мелких задач на вполне себе постоянной основе. Не говорю уже о тенденции последних лет, когда встречаются компании, которые как раз целенаправленно, с целью именно сокращения OPEX, переводят штатных разработчиков в на форму взаимоотношений по типу ГПХ/СМЗ/ИП (нет больничных/отпускных, других страховых отчислений от работодателя + техническое обеспечение такого "сотрудника" ложится также полностью на него самого). Все это в конечном итоге в реальности тоже ведь аутсорс, хоть и принимает такие странные формы.
В больших компаниях с развитой инфраструктурой и достаточными ресурсами, вполне соглашусь - там именно таким подходам и следуют. Хотя и так не без ложки дёгтя бывает - даже там не все и не везде умеют и готовы решать вопросы с наполнением тестовых стендов необходимыми для их корректной работы данными.
Ограничивать разработчиков в доступах на прод вполне логичный шаг и с этим массово в последние года все меньше проблем становится, но вот процессы создания тестовых стендов крайне желательно тщательно изучать. Обычно существуют довольно хорошо реализованные на стороне инфраструктуры мониторинги и контроли на доступы из тестовых сегментов в прод, но вот об обратном взаимодействии все ещё мало кто сходу задумывается.
Слияние всех описанных выше факторов может порождать, в какой-то момент, "интересные" открытия вида - тестовый стенд = реплика с прода 1-7-14-30 дневной давности. И хорошо ещё, если это по итогу быстро можно обнаружить в рамках каких-либо автоматизированных проверок тестовых сред, а не всплывает как-нибудь невзначай, либо вообще на инциденте.
Крайне похвальная тяга к саморазвитию - искренне желаю успехов на этом тернистом пути.
Спасибо за комментарий, изучим и постараемся, по возможности, учесть в будущем.
К сожалению, как раз в более чем 95% случаях продукты 1С используются по прямому назначению и содержат все те самые выплаты/зарплаты и разнообразные ПДн сотрудников, клиентов, контрагентом.
Я бы тут даже расширил тогда, так как этот постулат, в конечном итоге, легко масштабируется и на любую иную систему.
Самая безопасная эта та система, которая потушена, и к ней не имеют ни логического ни физического доступа никто, но само собой в реальности так нельзя сделать и вот тут уже и начинается борьба компромиссов удобства/работоспособности/безопасности.
При таких размерах компании, если бы их не было, было бы очень и очень больно.
То, что описано в статье выше - собирательный образ основных узких мест, которые встречались при столкновении с продуктами 1С и процессами, построенными на них в разного размера и направленности бизнеса компаниях.
Смысл прост - представьте, что вы относительно новичок в ИБ, продукты 1С встречали тольк на слуху, пришли в новую компанию, а там вам говорят, что ценным активом для бизнеса являются продукты 1С и их хотелось бы проаудировать и привести в порядок.
А тут дьявол кроется в деталях - это стоимость только лицензий на 1 год или железа+внедрения+настройки+сопровождения+реагирования? Купить любой инструмент мало, надо уметь его внедрить в процессы, развивать и поддерживать потом. В случаях с малым и средним бизнесом, отпугивает не стоимость лицензий чаще, а то, какие накладные расходы это понесет за собой на дистанции.
Да и будем честны - DLP не панацея и любой из тех, кто плотно работал с этим классом продуктов, внедрял, решал проблемы и разгребал инциденты, писал исключения, может с уверенностью сказать, что обойти его не то чтобы невозможно. Само решение хорошее, но оно должно работать в комплексе с отстроенными процессами - классические подходы "всем все запретить" сейчас уже не пройдут.
В контексте больших проектов и крупных компаний я вполне согласен с вами - там действительно цель совсем не в урезании костов, а в ускорении сроков реализации проекта (в особенности, если своей необходимой экспертизы нет/мало, а растить ее долго).
Но не стоит тут забывать про формы сотрудничества типа ГПХ/СМЗ или небольших ИП - они вполне могут привлекаться для более мелких задач на вполне себе постоянной основе. Не говорю уже о тенденции последних лет, когда встречаются компании, которые как раз целенаправленно, с целью именно сокращения OPEX, переводят штатных разработчиков в на форму взаимоотношений по типу ГПХ/СМЗ/ИП (нет больничных/отпускных, других страховых отчислений от работодателя + техническое обеспечение такого "сотрудника" ложится также полностью на него самого). Все это в конечном итоге в реальности тоже ведь аутсорс, хоть и принимает такие странные формы.