Comments 61
— Может, логи посмотреть? – ехидно спросил Стас. – Логи-то на что?
— За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.
Use grep, Luke!
Я так понимаю, эти ребята в итоге собираются лично записывать логи запросов прав доступа, а потом в реальном времени задавать пользователям вопросы и делать выводы. И их не смущает то, что проблема длится годами, и возможно права вручную тоже годами придётся выдавать, прежде чем что-то найдут.
Не слишком эффективно.
Я не с ними, если что.
Если проблема длится годами, а при попытке закрыть топорным методом в лучшем случае заметаются следы, то проблема активна и присутствует в настоящий момент. То есть, кто-то лезет не в своё дело слишком часто. Я бы, пожалуй, тут не просто "точечно права повыдавал", а ещё и с флагом audit, то есть, если прав у пользователя реально нет, система действует так, как если они есть, но логирует действия. SELINUX=permissive такой.
Вообще, проблема в том, что они не знают, что им искать. "Как" — use grep, Luke, а "что" — а хрен его знает, на непосвященный взгляд все действия являются валидными. Судя по описанию, прямого уничтожения записей в этом случае нет, т.е. злонамеренные действия не выпирают из БД вот прям явно. Систематизировать права доступа — хороший ход, но проверка корректности их применения должна быть двойной — админ смотрит, кто нарушает, и идет с этим к управляющему системой с той стороны с вопросом "положено ли вот этому пользователю вот такие вещи творить", и корректирует права с аудитом сообразно полученным данным. При подозрении на мухлёж со стороны управляющего — к директору, если уже он мухлюет, то стараться смысла нет, и пора валить (с).
Я бы, пожалуй, тут не просто "точечно права повыдавал", а ещё и с флагом audit
Я предполагал, что если у них есть логи и возникла идея их посмотреть, то в логах уже отражены похождения всех пользователей за несколько лет (то есть аудит уже ведётся), достаточно только перебрать ~пару гигабайт (или не пару) информации и дальше можно докладывать начальству. Это можно сделать по-тихому, без необходимости провокаций, ведь всё совершённое уже отражено в логах. И не обязательно перебирать все логи.
Серьёзно дорабатывать информационную систему (вкладывать ресурсы), а потом сообщать пользователям, что им нужно будет согласовывать правки с начальством, и ждать, что они продолжат косячить под бдительным надзором — стратегически неправильно.
Вообще, проблема в том, что они не знают, что им искать. "Как" — use grep, Luke, а "что" — а хрен его знает, на непосвященный взгляд все действия являются валидными.
Так-то да, но, имхо, они должны были разобраться и вместе с начальством или знающими людьми придумать какие-то инварианты, которые можно автоматизированно проверять, и затем вручную рассматривать сомнительные случаи. Если эти косяки будут концентрироваться у некоторых пользователей — вопросы к ним.
Я сталкивался с подобным, но более простым из-за отсутствия финансового интереса пользователей, случаем (где-то в локалке завёлся вирус-спамер), помогло как раз включение логгирования и анализ логов на следующее утро.
в логах уже отражены похождения всех пользователей за несколько лет (то есть аудит уже ведётся)
Вполне может быть, что в логах есть не всё, так как тогда настраивали на насущные действия, а сейчас сменился приоритет. То есть даже от просмотра логов с грепом может не оказаться пользы.
Серьёзно дорабатывать информационную систему (вкладывать ресурсы), а потом сообщать пользователям, что им нужно будет согласовывать правки с начальством, и ждать, что они продолжат косячить под бдительным надзором — стратегически неправильно.
Тут согласен, но я предложил другую модель поведения системы — пользователь сам ничего не согласовывает, но его "неправильные" действия в системе логируются (отдельно), админы их сами по своей инициативе согласовывают с начальством и выясняют, насколько это легальные (были) действия, и если таки да, меняют правила аудита, чтобы это от этого пользователя не логировалось, так как ему можно. А согласовывать каждый чих и впрямь не набегаешься, вся работа колом встанет от первой же фактической ошибки.
имхо, они должны были разобраться и вместе с начальством или знающими людьми придумать какие-то инварианты, которые можно автоматизированно проверять, и затем вручную рассматривать сомнительные случаи.
Я прочел текст так, что из него следует, что они не знают, что вообще является сомнительным случаем, и из-за этого и кипишуют.
Подумаешь, поставить весь процесс раком, ведь каждый бух для каждой операции должен будет в IT-отдел на поклон идти…
Подумаешь, после второго-третьего раза это будет отменено с самого верха…
Ура, прода!
выяснять причины, конечно, нужно. без этого не обойтись. но иногда эти причины достаточно субьективные (не успела-забыла-не подумала о последствиях).
и проблемы _предотвращаются_ тем, что пользователь понимает: косяк будет зафиксирован, косяк придется как минимум объяснять, а то и отвечать. И возникает дилемма: косячить по-минимуму, или накосячить и свалить.
смотрим её движения по документам/кто именно в них ковырялся и логи действия именно этого пользователя за этот период
Всё это можно делать и не обрезая права. Точнее даже сказать, что это вообще не связанные вещи: изменение прав и аудит.
И опять же исходя из этого аналогия вообще не к месту смотрится. Дырка в заборе — это когда у человека нет прав, на то, что бы входить/выходить, но он находит путь в обход системе разделения доступа. А в данном случае все ходят через проходную, но предлагается на этой проходной ворота не открывать, пока человек не скажет куда идёт.
Есть дыра – полные права у всех.
Просто просят всем полные права дать, чтобы работа колом не вставала, если что-то не получится.
Т.е. просто у всех root права
Насколько я понял нет нормального аудита и его отсутствие хотят заменить точечными правами. Например, проблема с документом 5X-18, а к этому документу имеет права доступа только Катя, значит она и косячит.
В общем, самый что ни на есть костыльный способ решения проблемы.
Примеров такой ситуации есть масса:
Кладовщику никто не вменил в обязанности списывать детали в момент отгрузки, он их отмечает скопом в конце недели, когда его никто не беспокоит.
В системе отметок нет, поэтому начальник производства или логист выкручиваются как могут, например могут по косвенным признакам — отгрузка заказа, понять что детали со склада ушли. И они закрывают заказ целиком, автоматически проставляя отметку что детали со склада ушли. Вроде все нормально, но потом окажется, что детали со склада не брали, а так как было срочно, а кладовщика(или деталей) не было — взяли с менее срочного заказа. Но по этому менее срочному заказу детали уже списаны со склада и по текущему получается тоже. А по факту со склада ушел только один комплект, а не два.
На следующей неделе нач.производства приходит за недостающей деталью, а ему кладовщик говорит, что дать еще не может. И вообще по его системе все уже выдано и предлагает нач. производству оформить акт брака на уже выданное и он по нему выдаст недостающий комплект. Нач.производства такое устроит, а вот по документам со склада ушло три комплекта, а по факту два.
Что будет в конце месяца при аудите? Излишек. Но это же в плюс кладовщику, так что его вроде как наказывать не за что. А если выдается очень много деталей то концы найти очень и очень тяжело. А если за кем-нибудь еще и косяк будет, то почти невозможно, так как еще и следы будут скрывать. Только засаду готовить и остается.
Подобных ситуаций может быть масса — а на вопрос кладовщику, какого органа он сразу не списывает. Вполне может лежать ответ в области решений руководства:
-дикий перегруз потому что начальство экономит на фонде ЗП
-невозможно делать физически. Компьютер стоит черти где.
-Кладовщик пришел только 2 месяца назад и ему никто не говорил и никто не требовал этого(без бумажной инструкции и подписи почти непроверяемо)
-Кладовщик ушел в отпуск, вместо него поставили уборщицу бабу Нюру, которая детали все знает, так как работала раньше на предприятии на рабочей должности, но с компьютером совершенно не может работать. И за нее вбивает данные начальник, но раз в несколько дней — как будет свободен и вообще вспомнит про это.
— и т.д. и т.п.
Здесь вопрос в организации и координации. Кто что делает, для чего(какой будет результат), оценены риски и проблемные точки, как именно будут решаться конфликтные и форсмажорные ситуации. Если это прописать тогда уже будет вопрос по правам доступа. А иначе получится автоматизация бардака и борьба с поносом запиранием туалета))))
Ну а после естественно вопрос контроля. Все ли участники системы работают как запланировано.
меняет данные задним числом
А что в этом плохого? Ошибки исправляются, коррекции вносятся.
Далеко не все программы позволяют просто добавить товар на склад, так как в предыдущей операции была ошибка.
А требовать безошибочности от пользователей вообще идиотизм. Тогда народ не работать будет, а документы перепроверять по 100 раз. Это всё равно, что требовать формальной верификации для всех программ, в том числе для косынки.
Отсутствие аудита и истории изменений — вот это плохо.
Требовать безошибочности нельзя. но свести раздолбайство к минимуму — надо стараться.
Если обнаружена ошибка, её по возможности надо корректировать в текущем периоде, а не править приход/расход 3 квартала назад.
Откуда эти голословные заявления? А если система требует, чтобы выплата по договору и заключение договора происходила с одним предприятием, то что делать для случае, когда права переходят к другому (т.е. Медиа Маркт закрылся, по гарантии отвечает МВидео)? А систему править нельзя, так как внешний вендор не собирается этим заниматься.
Далее: а что если человек оформляет overtime задним числом? Например, в пятницу вечером была запара, в бухгалтению не успели сбегать.
Самое важное: система должна быть для людей, а не для формальностей. git позволяет изменять историю. Да и все остальные системы тоже. И это не просто так.
вот реальный пример: продажникам дали задание срочно слить остатки товара. продадут — премия. они — выполнили. а у бухгалтера «в пятницу была запара», и он «не успел оформить приход». оформил в понедельник. ничего страшного — продажники требуют заработаную приемию, начальство не выдает, потому, что на остатках товар есть — и у конкурентов он появился более дешевый.
Или другой реальный пример: товар был бракованый (у всех региональных дистрибуторов, кстати — чисто производственный брак), списание «решили оформить потом» (оформим задним числом, ничего страшного), а система подтвердил заявку торговой сети на этот товар. как вы догадываетесь, на количество, которое обычно сеть брала у 3 дистрибов. штрафы за недопоставку до 50%…
такие привычные мелочи, как штрафы от налоговой за расхождение в учете, или съехавшую себестоимость, продажи «в ноль» или «в минус» из-за добавления задним числом накладных расходов я и не говорю — рутина…
так для каких именно людей из вышеперечисленного «система должна быть»?
В общем, в вашем примере система отработала как надо. А если люди поняли свою ошибку, то вообще всё классно, бизнес идет. Это лучше, чем отсутствие продаж, так как нет прав добавить документ в файл, а айтишник уже вечером пивко пьет вдали от компа.
git позволяет изменять историю.
Дополню, что git, хоть и позволяет изменять историю, но очень противится этому. Если нужна существенно изменяемая история — лучше использовать что-то другое.
back on topic: ведь правила бухучёта не просто так придумали, и сторнирование, и бухгалтерские справки…
— Может, логи посмотреть? – ехидно спросил Стас. – Логи-то на что?
— За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.
Они что не могут выпустить отчеты на определенную дату ну бекап древний взять. Потом через время выпустить на эту же дату эти отчеты и сравнить. Все разночтения по остаткам будут видны.
фиксировать критичные остатки в той же базе
А что воровать по крохи и из-за объема получить существенную сумму нельзя?
Все изменения будут видны сейчас. А не через месяцы притом злоумышленник ляжет временно на дно.
И притом без никаких доработок и длительной раздачи прав. Что конечно правильно, но....
Желание
— Наша цель – понять, кто гадит в учете. Например, меняет движения по складу за прошлый месяц, или там за прошлый квартал.… А главное – ничего не узнаем. Поэтому сядем в засаде.
Дыру в заборе заделали, но вот что не увидели....
ну и я не столько про воровство (линейные бухгалтера крайне редко воруют), а про искажение учета из-за работы задним числом.
Да и к правам и логированию.
А вот Х знакома с Y который шантажирует Z который является сотрудником компании W которая дорабатывает эту систему. И Z меняет данные не через оболочку программы, а сразу в базе. Логирование конечно есть, но кто же смотрит логирование V, когда все действия в оболочке программы логируются в ней.
А вот сравнение может выявить и такой случай.
Парк, в котором протоптаны куча дорожек. Администрация решает облагородить парк.
Выделяет деньги на асфальтирование дорожек. Нанимает дизайнера, тот разрабатывает схемы дорожек с точки зрения красоты. Прокладывают дорожки и недоумевают потом как так, почему люди продолжают вытаптывать траву по своим дорожкам. Начинают городить ограждения и прочее. А что мешало сразу разобраться почему именно здесь люди вытоптали дорожку, а не левее на пару метров?
Т.е. это не дыра в заборе, а забор не на своем месте.
«Точечные права» у них появляются через годы существования проблемы, а решение — веселая «засада» (причем с предварительным информированием пользователей путем интервью) — як дити.
С другой стороны, концовка как-то смазана. И складывается впечатление, что руководители с системным мышлением оказываются обычными болтунами, когда у них самих дело доходит до принятия конкретного управленческого решения. А хочется больше позитива.
Система, которая легко и незаметно позволяет проводить чего-то задним числом… Выкинули бы ее, да завели амбарную книгу, раз не умеют ни в менеджмент, ни в безопасность, ни в аудит.
Эм, а я правильно понял конец, что изменения, которые «гадят» в систему вносят сами разработчики? :)
Или у меня извращенное мышление? :)
Вот он, узкоспециальный подход. Менеджер орёт, айтишник лезет в кофиги системы на горячую менять.
И только службе безопасности никто не удосужился сообщить о фактах саботажа и знонамеренных действий. Да кто они такие, сами справимся, в чингачкуков поиграем, детство вспоминал им.
Люди, человеки! Обо всех таких вещах нужно сообщать куда следует, а не заниматься самодеятельностью. Если СБ существует, конечно. Если нет — тады ой, сему месту бысть пусту.
В любом случае это дело СБ.
Сегодня злоумышленник гадит по мелкому, завтра всю базу раком поставит и все предприятие парализует.
ибо пока в статье речь шла о «проекте по наведению порядка на складе». если я решаю наводить порядок около дома — это не значит, что где-то там ходит вредитель, который умышленно мусорит и гадит (хотя, конечно, такое тоже исключать нельзя), а скорее всего люди «просто так» бросают мусор, а после — «по закону разбитых окон» — начинают бросать его еще больше…
— Итак, ситуация. – начал Сергей. – У нас несколько пользователей, бухгалтеров. У всех – полные права. И кто-то из них, вероятно, нам гадит в учете. Что делать?
— За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.
— Наша цель – понять, кто гадит в учете. Например, меняет движения по складу за прошлый месяц, или там за прошлый квартал.
Вы текст читали или только коменты?
Это не «проект по наведению порядка на складе», это конкретно просохаченая дыра в безопасности, о которой никому не сообщили долгое время, и теперь судорожно пытаются как то решить втихаря, чтобы не всплыло. Потому что большие дяди могут квалифицировать как халатность. Или заподозрить соучастие.
но это совершенно не означает, что «гадящий в учете» — саботажник, что он вообще действует намеренно и целенаправленно, а не решает "[интеллектуально] доступным ему способом" свои локальные проблемы.
как пример, в 2004 году сталкивался с тем, что «девочка», начислявшая зарплату, «чтоб не делать каждый раз новый документ», просто меняла дату у документа предыдущего месяца… она была не вредитель, а просто мелкая дура…
Самая вероятная версия — хищения. Ее и будут разрабатывать безопасники, причем не только анализом сетевой деятельности. Может статься, что у них уже есть на примете подозрительная кладовщица, но без доказательств.
Это бардак, но без хищений. хотя хищения тоже более чем возможны, особенно при бардачном учете (но они чаще следствие бардака)
Дальше будут качели — изменения в модели и реальности. Реальность сложна, попытка в лоб привести реальность к модели — приводит к росту бюрократизации и в конце концов проваливается из-за слишком больших накладных расходов на внесение данных в информационную систему. Попытка отразить реальность в модели — ведет к усложнению модели до полной неприменимости. Но каждая итерация порождает островки равновесия между сложностью модели и формализации реальности. Типа производственных линий и конвейеров, автоматизированных складов (Амазон и последователи), CRM, ERP и автоматизации бухгалтерии.
Если говорить конкретно о примере в серии статей, то одним из решений проблемы склада будет выделение части номенклатуры в склад особого учета с задроченными до состояния биороботов работниками (ну или с частичной или полной автоматизацией) и усложненной моделью в информационной системе. Естественно, внедрение и эксплуатация такого склада будет дороже обычного склада, поэтому предварительно надо будет произвести расчет расходов и издержек и уже их сравнить с ожидаемым повышением прибыли. Вполне может оказаться, что это решение экономически невыгодно в момент оценки и бардак останется нетронутым. Перерасчет решения можно производить периодически и/или при появлении/изменении существенных факторов (ну например появление в продаже роботизинованных складов с подходящими параметрами единиц хранения — веса и размера).
Дыра в заборе, Эффективные менеджеры и Инженеры