F
Size: a a a
2020 March 02
VS
Итак. Требования:
1. База данных находится в защищенном контуре.
2. Приложение на PHP развертывается вне защищенного контура, на неподконтрольном сервере. Код открыт и может быть модифицирован сторонним недоверенным разработчиком.
3. Требуется аудит любого CR?UD действия с данными, которое производит приложение из пункта 2: кто, когда и что делал
4. Аудит не не системном уровне (запросы), а на уровне бизнес-процессов.
Расскажите, пожалуйста, как тут обойтись без «логики в базе»?
1. База данных находится в защищенном контуре.
2. Приложение на PHP развертывается вне защищенного контура, на неподконтрольном сервере. Код открыт и может быть модифицирован сторонним недоверенным разработчиком.
3. Требуется аудит любого CR?UD действия с данными, которое производит приложение из пункта 2: кто, когда и что делал
4. Аудит не не системном уровне (запросы), а на уровне бизнес-процессов.
Расскажите, пожалуйста, как тут обойтись без «логики в базе»?
сочувствую.. Уже бы и бд засунули в незащищенный контур, чтобы более экстремально было.
АС
сочувствуете? чему?
АС
тому, что бывают такие задачи?
АС
да, это не сайтики с админками
DT
Программисты: рвут жопу, натягивают сову на глобус, но пытаются делать возможность создания изоморфных приложений.
Пхпшики: не вижу ничего плохого в хранении бизнес логики в бд
Пхпшики: не вижу ничего плохого в хранении бизнес логики в бд
ЕР
Итак. Требования:
1. База данных находится в защищенном контуре.
2. Приложение на PHP развертывается вне защищенного контура, на неподконтрольном сервере. Код открыт и может быть модифицирован сторонним недоверенным разработчиком.
3. Требуется аудит любого CR?UD действия с данными, которое производит приложение из пункта 2: кто, когда и что делал
4. Аудит не не системном уровне (запросы), а на уровне бизнес-процессов.
Расскажите, пожалуйста, как тут обойтись без «логики в базе»?
1. База данных находится в защищенном контуре.
2. Приложение на PHP развертывается вне защищенного контура, на неподконтрольном сервере. Код открыт и может быть модифицирован сторонним недоверенным разработчиком.
3. Требуется аудит любого CR?UD действия с данными, которое производит приложение из пункта 2: кто, когда и что делал
4. Аудит не не системном уровне (запросы), а на уровне бизнес-процессов.
Расскажите, пожалуйста, как тут обойтись без «логики в базе»?
Можно сразу поставить требование "логику писать в БД", чё уж)
ЕР
И пусть выкручивается
ЕР
Тож не сайтик с админкой)
АС
Коллеги, если кто-то из вас не видел в жизни слона, это не значит, что нужно заниматься отрицанием его существования...
F
Итак. Требования:
1. База данных находится в защищенном контуре.
2. Приложение на PHP развертывается вне защищенного контура, на неподконтрольном сервере. Код открыт и может быть модифицирован сторонним недоверенным разработчиком.
3. Требуется аудит любого CR?UD действия с данными, которое производит приложение из пункта 2: кто, когда и что делал
4. Аудит не не системном уровне (запросы), а на уровне бизнес-процессов.
Расскажите, пожалуйста, как тут обойтись без «логики в базе»?
1. База данных находится в защищенном контуре.
2. Приложение на PHP развертывается вне защищенного контура, на неподконтрольном сервере. Код открыт и может быть модифицирован сторонним недоверенным разработчиком.
3. Требуется аудит любого CR?UD действия с данными, которое производит приложение из пункта 2: кто, когда и что делал
4. Аудит не не системном уровне (запросы), а на уровне бизнес-процессов.
Расскажите, пожалуйста, как тут обойтись без «логики в базе»?
Говноархитектура детектед.
1. Збс
2. Суём приложение на PHP в защищённый контур. С ACL-ями, файрволлами, доверенными лицами, безопастниками, пентестами, сертификациями железа и талонами на талоны. Аудит каждого релиза - даже патч и минорного. Как в ФСБ и военной приёмке.
3. Логи на уровне приложения, правильная организация доступа (либы, модули, etc). А ещё злые какеры могут слить БД через mysqldump или аналог, и до бороды тот аудит в хранимых процедурах.
4. См. п.3, только в advanced-варианте, долго писать.
1. Збс
2. Суём приложение на PHP в защищённый контур. С ACL-ями, файрволлами, доверенными лицами, безопастниками, пентестами, сертификациями железа и талонами на талоны. Аудит каждого релиза - даже патч и минорного. Как в ФСБ и военной приёмке.
3. Логи на уровне приложения, правильная организация доступа (либы, модули, etc). А ещё злые какеры могут слить БД через mysqldump или аналог, и до бороды тот аудит в хранимых процедурах.
4. См. п.3, только в advanced-варианте, долго писать.
АС
И тем более не стоит вести непримиримую борьбу против слонов, аргументируя это тем, что и коров на всех хватит.
VS
Коллеги, если кто-то из вас не видел в жизни слона, это не значит, что нужно заниматься отрицанием его существования...
Все мы знаем, что слоны существуют, но видим их раз в жизни.
АС
2. Это невозможно, приложение тиражное и разворачивается на серверах конечного клиента.
3. Логи вам не помогут при наличии физического доступа к файлам приложения недоверенного лица. См. п. 2. Разработчик просто перенаправляет все логи в /dev/null и всё.
4. Нет задачи «не давать данные», есть задача - аудит доступа к данным.
3. Логи вам не помогут при наличии физического доступа к файлам приложения недоверенного лица. См. п. 2. Разработчик просто перенаправляет все логи в /dev/null и всё.
4. Нет задачи «не давать данные», есть задача - аудит доступа к данным.
F
2. Это невозможно, приложение тиражное и разворачивается на серверах конечного клиента.
3. Логи вам не помогут при наличии физического доступа к файлам приложения недоверенного лица. См. п. 2. Разработчик просто перенаправляет все логи в /dev/null и всё.
4. Нет задачи «не давать данные», есть задача - аудит доступа к данным.
3. Логи вам не помогут при наличии физического доступа к файлам приложения недоверенного лица. См. п. 2. Разработчик просто перенаправляет все логи в /dev/null и всё.
4. Нет задачи «не давать данные», есть задача - аудит доступа к данным.
2. Не зная деталей, я не могу делать дальнейшие выводы. В первом варианте "ТЗ" всё было возможным. В этом я тоже вижу пути решения, хоть и более сложные, в первую очередь, организационно.
3. Такой доступ, очевидно, должен быть исключён. Про аудит, к тому же, я не просто так писал. Погуглите, как это делается в указанных мною силовых структурах, очень удивитесь уровню погружения аудиторов.
3. Такой доступ, очевидно, должен быть исключён. Про аудит, к тому же, я не просто так писал. Погуглите, как это делается в указанных мною силовых структурах, очень удивитесь уровню погружения аудиторов.
VS
2. Это невозможно, приложение тиражное и разворачивается на серверах конечного клиента.
3. Логи вам не помогут при наличии физического доступа к файлам приложения недоверенного лица. См. п. 2. Разработчик просто перенаправляет все логи в /dev/null и всё.
4. Нет задачи «не давать данные», есть задача - аудит доступа к данным.
3. Логи вам не помогут при наличии физического доступа к файлам приложения недоверенного лица. См. п. 2. Разработчик просто перенаправляет все логи в /dev/null и всё.
4. Нет задачи «не давать данные», есть задача - аудит доступа к данным.
Представляю себя. Прихожу на собес к Альберту и он мне излагает бизнес требования, излагает, что всё на процедурах пишут. Я бы развернулся и ушел. Как вы людей набираете?
АС
Нормально набираю
АС
А что?
АС
Всегда есть те, кому интереснее погрузиться чуть глубже, чем банальный HTTP API CRUD