Ограничение использования /usr/sap/trans

Автор Skif, Лютий 26, 2008, 05:15:42 ПП

Попередня тема - Наступна тема

0 Користувачі і 1 Гість дивляться цю тему.

Skif

Как можно наложить ограничения на расшаренный /usr/sap/trans, чтобы его можно было юзать только под транспорт запросов и только в одну сторону? Чтобы абапом в PRD нельзя было сбросить туда файло, а из DEV - прочитать..-  ну так - навскидку ))
p.s. из серии параноидных...

sapzvezda

Цитата: Skif від Лютий 26, 2008, 05:15:42 ПП
Как можно наложить ограничения на расшаренный /usr/sap/trans, чтобы его можно было юзать только под транспорт запросов и только в одну сторону? Чтобы абапом в PRD нельзя было сбросить туда файло, а из DEV - прочитать..-  ну так - навскидку ))
p.s. из серии параноидных...

Транспортная директория ведь расшаривается на уровне ОС только для пользователей, созданных для SAP-систем. Если расшарили /trans для кого-то еще, то надо зашарить обратно. Навскидку. А еще пасти АБАП-код, который поступает в продуктив. Это из параноидальной серии =)

№1

Точно не помню название объекта (кажется, S_DATASET), но с его помощью легко регулируется возможность работы с любой файловой системой на сервере.
Мой блог

Uukrul

Цитата: sapzvezda від Лютий 27, 2008, 08:21:46 ДП
Навскидку. А еще пасти АБАП-код, который поступает в продуктив. Это из параноидальной серии =)
О, брат это не поможет... потому как динамические программы и код через таблицы паси/непаси, а все равно если очень хочется, то можно и обойти полянки для выпаса... тут с другой стороны надо подходить.

Skif

Цитата: Uukrul від Лютий 27, 2008, 09:31:27 ДП
О, брат это не поможет... потому как динамические программы и код через таблицы паси/непаси, а все равно если очень хочется, то можно и обойти полянки для выпаса... тут с другой стороны надо подходить.
Абап-код не рассматриваем - считаем, что программа уже содержит эксплойт любого уровня (хоть скрипт хоть, жаба-код) - это добро уже появляется, как мы все знаем ))
А учитывая шаловливые ручонки малолетних девелОперов, ограничить их творчество в рамках системы.
Что там с физикой...деблокируем с целью - файло (с определённым шаблоном) под юзером DEVadm падает в trans...- значит доступ на запись ..
хм...надо поглядеть, что там твориться..а то забыл ))

sapzvezda

2 Uukrul
С другой, это с которой?

2 Skif
Если в системе такой беспредел твориться, то зачем малолетнему девелоперу нужен /trans? Когда можно выгружать в любую расшаренную папку в сети. Логики борьбы не улавливаю.

Skif

Цитата: sapzvezda від Лютий 27, 2008, 11:03:07 ДП
2 Skif
Если в системе такой беспредел твориться, то зачем малолетнему девелоперу нужен /trans? Когда можно выгружать в любую расшаренную папку в сети. Логики борьбы не улавливаю.
дай подумать )))
если с системой работают только доверенные лица/места, то транзит инфы возможен только по транпортной цепи в обратную сторону.
если же нет, то можно выгрузить что угодно на клиента....или воще отправить по его почте так , что он и знать не будет...
мдя...хорошо б собраться на базисник - пообсуждать в "узком кругу" ))

Uukrul

Цитата: sapzvezda від Лютий 27, 2008, 11:03:07 ДП
С другой, это с которой?
Ну персонал надо подбирать, да кормить его по лучше, чтобы ему было не надо было изгаляться для левого доступа к продуктивным системам... опять же зачем ему эти доступы, ну только чтобы толкнуть куда информацию потом как я понимаю. Так что бороться желательно с причиной, а не последствиями.

В качестве отступления: В СССР например боролись не так с получением доступов  к информации, как с каналами передачи, собственно на этих самых каналах передачи в основном и горели как те кто получал, так и те кто предавал. А вот появился интернет и теперь с передачей проблем ну совсем нет, а всякие сормы и прочая фигня вещь конечно для ламера страшная, но кому надо всегда могут это дело обойти, да хотя бы путем захода в любой компьютерный клуб и у людей реально возникли проблемы... а потому что ловили передачу, а вот ловить доступы у не научились.

Так и тут, против хорошего абапера, который задался целью чего-то там где-то посмотреть в продуктиве, то уж поверьте он это посмотрит и узнает.

sapzvezda

Цитата: Uukrul від Лютий 27, 2008, 11:29:57 ДП
Ну персонал надо подбирать,

Ок. Имеем хорошего абапера. И имеем хорошую систему. Абапер должен что-то разрабатывать в системе разработки только в соответствии с заданием/проектным решением. Со всем остальным рукоблдудством, добро пожаловать в рукоблудную систему, которая варится отдельно. Соответственно пронос запросов от абаперов самым тщательным образом должен контролироваться, а их содержимое хотя бы поверхностно проверяться и на соответствие исходному заданию. В продуктив у абапера доступа быть не должно. Разве что из-за плеча у пользователя. Далее, если в программе зашит какой-то вредоносный код, этот код должен быть активирован путем некоторых манипуляций (хотя активацию можно привязать к определенной дате и времени). Из организационных мер, оформить разработчику доступ к служебной информации, со всеми вытекающими последствиями, в случае хищения/порчи. Из технических мер. Тут можно изголяться сколь угодно долго, вплоть до подключения к ПК только проверенных и авторизованных флешек и запрета шар.

Skif

Цитата: sapzvezda від Лютий 27, 2008, 12:02:17 ПП
Ок. Имеем хорошего абапера. И имеем хорошую систему. Абапер должен что-то разрабатывать в системе разработки только в соответствии с заданием/проектным решением. Со всем остальным рукоблдудством, добро пожаловать в рукоблудную систему, которая варится отдельно. Соответственно пронос запросов от абаперов самым тщательным образом должен контролироваться, а их содержимое хотя бы поверхностно проверяться и на соответствие исходному заданию. В продуктив у абапера доступа быть не должно. Разве что из-за плеча у пользователя. Далее, если в программе зашит какой-то вредоносный код, этот код должен быть активирован путем некоторых манипуляций (хотя активацию можно привязать к определенной дате и времени). Из организационных мер, оформить разработчику доступ к служебной информации, со всеми вытекающими последствиями, в случае хищения/порчи. Из технических мер. Тут можно изголяться сколь угодно долго, вплоть до подключения к ПК только проверенных и авторизованных флешек и запрета шар.
а если имеем неплохого абапера, по совместительству базисника, которому просто нравится "душить котов"? ))

sapzvezda

Цитата: Skif від Лютий 27, 2008, 01:58:07 ПП
а если имеем неплохого абапера, по совместительству базисника, которому просто нравится "душить котов"? ))

Есть такая подборка Воины Интернета http://asher.ru/other/warriori/index.html
Если провести аналогию с SAP, то базисник в той иерархии Админ. Т.е. самый сильный воин =)

Skif

Цитата: sapzvezda від Лютий 27, 2008, 12:02:17 ПП
Ок. Имеем хорошего абапера. И имеем хорошую систему. Абапер должен что-то разрабатывать в системе разработки только в соответствии с заданием/проектным решением.
Даже боюсь задавать вопрос - как вы оцениваете уровень надёжности отечественных консалт-компаний в части гарантий сохранности тайны информации компаний-клиентов?

Uukrul

Цитата: Skif від Лютий 27, 2008, 02:59:18 ПП
Даже боюсь задавать вопрос - как вы оцениваете уровень надёжности отечественных консалт-компаний в части гарантий сохранности тайны информации компаний-клиентов?
А что были прецеденты? Или это так... из раздела общей эрудиции вопрос?

sapzvezda

Цитата: Skif від Лютий 27, 2008, 02:59:18 ПП
Даже боюсь задавать вопрос - как вы оцениваете уровень надёжности отечественных консалт-компаний в части гарантий сохранности тайны информации компаний-клиентов?


Не возьмусь давать подобную оценку. Конечно, соглашение о конфиденциальности сейчас подписывают все кому не лень, но как это на практике работает, мне неизвестно. Все таки к серьезной системе не любого консультанта подпустят. А когда подпускают, то жестко контролируют.

Детали проектных решений, разнообразных "находок" и ноу-хау, да и многая другая проектная документация естественно кочует вместе с консультантами-кочевниками. От этого никуда не деться =)

Skif

Цитата: Uukrul від Лютий 27, 2008, 03:07:34 ПП
А что были прецеденты? Или это так... из раздела общей эрудиции вопрос?
"у вас несчастные случаи на производстве были? - будут" )))
так...почитал просто - http://lenta.ru/news/2008/02/27/lgt/

Skif

Цитата: sapzvezda від Лютий 27, 2008, 03:12:42 ППА когда подпускают, то жестко контролируют.
Боюсь ошибиться, но для "жесткого контроля" требуется квалификация не ниже...как следствие - соответствующая оплата...сомневаюсь, что где-то заплатят "контролёру" хотя бы половину того, что платят консалтеру. или есть преценденты? :)

Uukrul

Цитата: Skif від Лютий 27, 2008, 03:12:53 ПП
"у вас несчастные случаи на производстве были? - будут" )))
так...почитал просто - http://lenta.ru/news/2008/02/27/lgt/
Ну это из другой оперы... это сотрудник так сказать поработал, а не привлеченный консалт.

Uukrul

Цитата: Skif від Лютий 27, 2008, 03:17:58 ПП
Боюсь ошибиться, но для "жесткого контроля" требуется квалификация не ниже...как следствие - соответствующая оплата...сомневаюсь, что где-то заплатят "контролёру" хотя бы половину того, что платят консалтеру. или есть преценденты? :)
Естественно так и есть... а поэтому как ни крути глобальная безопасность стоит очень дорого.

Skif

Цитата: Uukrul від Лютий 27, 2008, 03:21:51 ПП
Ну это из другой оперы... это сотрудник так сказать поработал, а не привлеченный консалт.
сотрудников, кстати, опекают свои "контролёры" достаточно жёстко - на это у них хватает компетенции

Skif

Цитата: Uukrul від Лютий 27, 2008, 03:24:07 ПП
Естественно так и есть... а поэтому как ни крути глобальная безопасность стоит очень дорого.
просто нуно не морочить голову клиенту, а честно сказать, что работаем "на доверии"

Uukrul

Цитата: Skif від Лютий 27, 2008, 03:31:17 ПП
просто нуно не морочить голову клиенту, а честно сказать, что работаем "на доверии"
Ну на самом деле консалт подписывает с документами на услуги так же и форму так называемого соглашения о не распространении полученной коммерческой информации, поэтому доверие, доверием, но в случае чего... всегда можно привлечь недобросовестный консалт. Кстати в общем плане, все равно все заключается только в доверии, так как я сомневаюсь, что кто-то знает какие другие механизмы которыми можно закрыть информацию, только доверие, а все эти бумаги... ну это типа хоть как-то прикрыть задницу если что.

Цитата: Skif від Лютий 27, 2008, 03:31:17 ПП
просто нуно не морочить голову клиенту, а честно сказать, что работаем "на доверии"
Ну это не худший вариант... думаю в приведенной ссылке тоже не клювом клацали, а все ж таки прохлопали...

sapzvezda

Цитата: Skif від Лютий 27, 2008, 03:17:58 ПП
Боюсь ошибиться, но для "жесткого контроля" требуется квалификация не ниже...как следствие - соответствующая оплата...сомневаюсь, что где-то заплатят "контролёру" хотя бы половину того, что платят консалтеру. или есть преценденты? :)

Я не представляю продуктивную систему, которая эксплуатируется (внедрение не рассматриваем) продолжительное время и к которой взяли и подпустили рядового консультанта из первой-попавшейся консалтинговой конторы. А если подпустили, то почему бы рядом с ним не посидеть и не проконтролировать, что он делает.

Uukrul

Цитата: sapzvezda від Лютий 27, 2008, 03:42:14 ПП
Я не представляю продуктивную систему, которая эксплуатируется (внедрение не рассматриваем) продолжительное
Я тоже... не представляю, но как говорится и проверенные могут дров наломать ::)

Skif

Цитата: sapzvezda від Лютий 27, 2008, 03:42:14 ППА если подпустили, то почему бы рядом с ним не посидеть и не проконтролировать, что он делает.
многие соглашаются на удалённое внедрение. собственно консалт разрабатывает что-то у себя, проводит тест на QAS и если не сам, то базису клиента ставит в очередь запросы в PRD. Зачастую и систему ставит удалённо (включая PRD). Так что шансов контроля никаких.

Uukrul

Цитата: Skif від Лютий 27, 2008, 04:01:55 ПП
то базису клиента ставит в очередь запросы в PRD. Зачастую и систему ставит удалённо (включая PRD).
Вот тут буквочки не правильные... клиенту тоже надо ставить в QAS и только после того как специалисты клиента/заказчик не проверит как оно там работает, только тогда клиент сам ставит эти запросы в очередь на продуктив, а до этого никаких PRD.