Size: a a a

Обсуждения техдирские

2019 August 30

AS

Andrey Shetukhin in Обсуждения техдирские
Viacheslav Kaloshin
Обалдеть. Я давно уже реальных почтовых пользователей не видел в системах:) а оно вон чего оказывается, живо ещё :)
У меня в проде есть сервер с софтом, собранным в 1993 году. Я не шучу. Энтерпрайз такой энтерпрайз
источник

VK

Viacheslav Kaloshin in Обсуждения техдирские
Andrey Shetukhin
У меня в проде есть сервер с софтом, собранным в 1993 году. Я не шучу. Энтерпрайз такой энтерпрайз
sendmail вечен :)
источник

AS

Andrey Shetukhin in Обсуждения техдирские
Вообще, я тут жуткую вещь напишу, но в современных условиях, когда машина разворачивается за 15 секунд из образа, а основная ценность - данные, всё равно от кого эти данные писать и читать.
Потому, что если процесс имеет доступ к данным на модификацию, их всё равно от какого пользователя портить.

А всё остальное деплоится мгновенно.
источник

AS

Andrey Shetukhin in Обсуждения техдирские
Что до совместного использования виртуальной машины и доступа к чужим данным, то просто не ставьте два сервиса на одну виртуалку или контейнер и всё
источник

rd

r d in Обсуждения техдирские
Я тут почитал переписку...
ПДН это вы про 152-фз? А то у меня это почему-то с делами несовершеннолетних ассоциируется. Но не суть.
В тех проектах, где у меня были ПД, они были в закрытом контуре, который наружу торчал только куском REST, в виде Get, и АРМами, на которых можно было посмотреть эти самые ПДН. Доступ внутрь контура был только у админов, но там мандатными метками на постгресе данные были закрыты, и у CTO, который был официально допущен к работе с ПДН. А если это не в рамках 152-фз, то сколько случаев хранения паролей в базе в открытом виде...
источник

rd

r d in Обсуждения техдирские
И вопрос доступа к продакшену в этом плане (с закрытыми контурами) тоже не стоит. Можно очень просить и умолять, но вот нет возможности взять и в закрытом контуре что-то пофиксить мимо регламента...
источник

rd

r d in Обсуждения техдирские
А ещё у меня был опыт работы на продакшене АЭС. Хорошо, что там не как в МТС. Впрочем, непонятно, как мы без этого жили...
Ну и слава богу, что живы.
источник

PD

Phil Delgyado in Обсуждения техдирские
r d
Я тут почитал переписку...
ПДН это вы про 152-фз? А то у меня это почему-то с делами несовершеннолетних ассоциируется. Но не суть.
В тех проектах, где у меня были ПД, они были в закрытом контуре, который наружу торчал только куском REST, в виде Get, и АРМами, на которых можно было посмотреть эти самые ПДН. Доступ внутрь контура был только у админов, но там мандатными метками на постгресе данные были закрыты, и у CTO, который был официально допущен к работе с ПДН. А если это не в рамках 152-фз, то сколько случаев хранения паролей в базе в открытом виде...
Ну вот это как раз нормальный подход. Закрытый контур и шифрование БД - стандартные требования.
источник

rd

r d in Обсуждения техдирские
Phil Delgyado
Ну вот это как раз нормальный подход. Закрытый контур и шифрование БД - стандартные требования.
Шифрования БД в самой БД не было. CTO заходил туда через простой psql и видел все данные. Операторы ПД заходили через АРМы и видели данные в рамках своего уровня доступа (как по записям, так и по атрибутам записи), но в интерфейсе.  
Но на аппаратном уровне было шифрование данных на диске, но это прозрачно для пользователей сисиемы. В принципе, это всё описано в различных нормативных документах в рамках ФЗ.
источник

rd

r d in Обсуждения техдирские
Собственно, у меня вызывает удивление оная дискуссия. Тем же мандатными метками в постгресе можно закрыть ПД для разработчиков при доступе на продакшен. Но зачем такое делать? Это уже явно косяк выше. И даже не в архитектуре, а в регламентах проекта/компании.
источник

rd

r d in Обсуждения техдирские
Подозреваю, что такое возможно и в оракле/ms sql/db2/прастихоспаде, но я про них не знаю, работаю с посгресом.
источник

rd

r d in Обсуждения техдирские
А в гипотетическом магазине кормов для животных хватит шифрования пароля так, чтоб радужные таблицы не работали, и то ладненько.
источник
2019 August 31

AK

Aleksandr Komlev in Обсуждения техдирские
Ruslan
С веб-мордой или без?
Понятно что под капотом может быть софт любой сложности. Но обычно разработчики почты пишут "мы разработчики почты" все таки. Когда пишут "веб", тогда обычно это сайты. Понятно что там под капотом все разное. Но человек бы вообще спрашивал такой вопрос, если у него софт должен работать под рутом.  Вопрос бы не стоял вообще.
У вас все разработчики имеют рут на прод, потому что там есть скрипт, который работает под рутом?
Очень сложно понять все эти суеверия про рут и права. Вы вот когда решаете попинговать хост не задумываетесь, что утилите ping нужен raw socket, потому что это ICMP, а socket(..., SOCK_RAW , ...) - это CAP_NET_ADMIN или минимум CAP_NET_RAW, а в реальности просто suid`-бит и запуск от владельца? А кто владелец? `root. То есть вы с самого начала повышаете привилегии на множество самых базовых действий. Тупо чтобы пингануть хост надо под рутом запускать бинарь, но без рутовых прав в общем случае!

Например, чтобы сделать bind на порт не нужен root, нужен setcap CAP_NET_BIND_SERVICE.

Да, заведомо ненадежное ПО (например, PHP-FPM или xMQ) следует ограничивать, давать капабилити необходимые для работы и выделять отдельного пользователя, однако это редко в действительности оправдано. Примерно так же как использование SELinux.
источник

AK

Aleksandr Komlev in Обсуждения техдирские
Ruslan
С веб-мордой или без?
Понятно что под капотом может быть софт любой сложности. Но обычно разработчики почты пишут "мы разработчики почты" все таки. Когда пишут "веб", тогда обычно это сайты. Понятно что там под капотом все разное. Но человек бы вообще спрашивал такой вопрос, если у него софт должен работать под рутом.  Вопрос бы не стоял вообще.
У вас все разработчики имеют рут на прод, потому что там есть скрипт, который работает под рутом?
Разработчику часто нужен рутовый доступ на продуктовый сервер, так что вопрос не в том стоит ли ему доверять, а как его выдать на время и только на нужные сервера? Старорежимный подход когда делается отдельный пользователь и ему выдается sudo чем-то вообще отличается от того чтобы просто выдать root? Ну только тем что потом можно понять кто именно натворил дел, но на самом деле нельзя, потому что auditd не работал. Негусто получается. А отзывать как? То есть подход изначально не имеет хороших шансов на успех.
источник

AK

Aleksandr Komlev in Обсуждения техдирские
Ruslan
В моем идеальном мире рут только у админа должен быть. Все, что делают программисты, запускается из под отдельных пользователей (обычно под каждый проект свой пользователь) и соответственно программисты, которым доступ на прод нужен, могут иметь доступ к файлам/данным этих пользователей.
Немного переведу на более понятный язык. В вашем идеальном мире ключи от дома только у папы, а все деньги только у мамы. Папа пускает маму и детей в дом, а мама им всем выдает деньги по необходимости. Идеал? Или горе детям таких родителей?
источник

ec

evgeny chikunov in Обсуждения техдирские
Если нельзя, но очень хочется... То надо заплакать и устроить скандал, и 2х2 станет равно 5. А по приказу главнокомандующего в военное время...
источник

АП

Александр Поволоцкий in Обсуждения техдирские
Andrey Shetukhin
У меня в проде есть сервер с софтом, собранным в 1993 году. Я не шучу. Энтерпрайз такой энтерпрайз
То есть, мой побежденный наконец биллинг на Санах 1998 года прекращения выпуска - это так, новодел?...
источник

PD

Phil Delgyado in Обсуждения техдирские
Aleksandr Komlev
Разработчику часто нужен рутовый доступ на продуктовый сервер, так что вопрос не в том стоит ли ему доверять, а как его выдать на время и только на нужные сервера? Старорежимный подход когда делается отдельный пользователь и ему выдается sudo чем-то вообще отличается от того чтобы просто выдать root? Ну только тем что потом можно понять кто именно натворил дел, но на самом деле нельзя, потому что auditd не работал. Негусто получается. А отзывать как? То есть подход изначально не имеет хороших шансов на успех.
А нафига разработчику рутовый доступ на прод? В каких сценариях он нужен часто?
источник

rd

r d in Обсуждения техдирские
Александр Поволоцкий
То есть, мой побежденный наконец биллинг на Санах 1998 года прекращения выпуска - это так, новодел?...
Если перейти на писькомерки, то в этом случае меньше...
источник

AS

Andrey Shetukhin in Обсуждения техдирские
Александр Поволоцкий
То есть, мой побежденный наконец биллинг на Санах 1998 года прекращения выпуска - это так, новодел?...
Работает - не трогай(с)
источник