Миссия невыполнима: Протокол Фантом (+спойлеры)

Вчера посмотрели новую "миссию".

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

Переход на VMWare ESXi 5

Тихой сапой прошел переход на VMWare ESXi 5.
Я участия в нем практически не принимал, только в самом конце, мне нужно было прокинуть USB-ключи на втором сервере и убедиться, что все работает нормально. Что, собственно, и было сделано.
В нашем случае все довольно просто, поскольку у нас есть два абсолютно одинаковых сервера, соединенных с NetApp'ом. Несколько недель назад мы "согнали" все виртуальные машины на один из них, чтобы убедиться, что в случае, если какая-то железяка на одном из них накроется, работа предприятия не остановится. Некоторые VM пришлось ужать по выделяемой процессорной мощности и памяти, но, поскольку, раздавали мы их "с запасом", проблем не возникло.
После того как VM некоторое время поработали на одном сервере, решили сразу все обновить. В результате, системный администратор накатил обновление на один из серверов и тут выяснилась интересная вещь. Оказалось, что usb-флэшки имеют свойство подыхать в самый неподходящий момент и существует вероятность, что перезагрузив однажды "железный" сервер, он не сможет подняться (поскольку ESXi грузится с флэшки). Очень так удачненько совпало, в итоге, у нас теперь есть запас флэшек с ESXi, регулярно обновляемых системным администратором :).
Сегодня утром перегнали все машины на обновленный сервер и обновили ESXi на второй машине. Пять часов, полет нормальный.
Очень понравилась возможность миграции виртуальных машин. Раньше не было повода ей воспользоваться. Если купим второй комплект ключей для 1С (мечты-мечты), возможно, получится делать миграцию и для сервера с 1С. А пока, попробовали мигрировать SQL-сервер. Активность пользователей в этот момент была почти нулевая и машинка "переехала" всего за 4 минуты.
Самая приятная, для меня, возможность ESXi 5 - это возможность отдавать одной машине больше четырех ядер. Меня этот момент очень смущал, когда мы решили виртуализировать SQL-сервера.
Вот как это выглядит:

На скриншоте видно, что теперь можно не только управлять количеством ядер, отдаваемых виртуальной машине, но и определять как гостевая ОС будет их видеть. Т.е., можно как раньше выделить, например, 4 "одноядерных" процессора, а можно выделить 2 двухядерных, или, как на скриншоте - 2 четырехядерных. Мне это очень по нраву.

А вот и она. Определенность

Вчера, в субботу, закончились мои курсы по "Защите персональных данных".
В понедельник меня ожидает зачет и, либо получение свидетельства о повышении квалификации, либо ничего. В любом случае курсом я очень доволен.
Были не очень понятные моменты, такие как, разбор предыдущей редакции закона о персональных данных - на это мы потратили два часа. Можно было провести это время более полезно. Второе, что не понравилось - составление частной модели угроз мы "рассмотрели" за 45 минут. Рассмотрели в кавычках, поскольку мы просто посмотрели "рыбу" документа "Частная модель угроз безопасности персональных данных" - из каких разделов она состоит и куда там можно запихнуть выдержки из "Базовой модели угроз". Подробного рассмотрения базовой модели тоже не было.
По плану на составление МУ было отведено 12 часов. Из-за того что преподователь чувствовал себя неважно, мы уложились в 2-3 часа. Считаю, что это очень мало, тем более, что частная модель угроз - это основной документ, от которого очень сильно зависит выбор средств защиты.
Из того, что лично мне понравилось больше всего - это формулировка об СТР-К.
"Поскольку персональные данные относятся к конфиденциальной информации, мы должны руководствоваться всеми документами по защите конфи, в том числе и СТР-К. Таким образом, коммерческое предприятие, руководствуясь СТР-К, делает вывод о том, что в соответствии с СТР-К, использование СТР-К для нее носит рекомендательный, а не обязательный характер.".
Это шикарно, я считаю. Мы, руководствуясь СТР-К, определяем, что мы не обязаны руководствоваться СТР-К.
Второй любопытный момент - вчера нам показывали SecretNet. Штука конечно интересная, но понравился комментарий преподователя о том, что в сетевой версии всегда присутствует центральная машина, на которую собираются ВСЕ логи с остальных машин сети, из-за чего сеть может проседать и в некоторых случаях приходилось отказываться от использования сетевой версии - т.е. на каждой машине в ИСПДн нужно устанавливать и настраивать SecretNet. Это, конечно, ппц.
Оказалось, что в случае если вендор не продлевает сертификат на какой-то продукт, мы можем сами запросить у ФСТЭК продление этого сертификата для ЕДИНИЧНОГО продукта. Т.е. никто не имеет права пользоваться этой штукой, а мы имеем. Здорово. В некоторых случаях, для упрощения продления сертификата, имеет смысл обратиться в одну из лабораторий, благо в Омске их штуки четыре есть.
По итогам курса выработал для себя определенный план действий, надеюсь, начальство его примет.
Поскольку ФСТЭК делает "замену" 58-му приказу (в соответствии с 19-й статьей измененного 152 ФЗ), работы по ТЗКИ лучше отложить до выхода новых положений (вот тут есть об этом). Хотя, конечно, если вдруг нарвемся на проверку будет плохо. Но предприятие, вроде готово к этому - от юристов и ген. директора поступало предложение оттянуть внедрение мер по защите как можно дольше.
Однако, до внедрения средств защиты можно сделать кучу вещей. Заняться организационно-распорядительной документацией, составить тот же перечень ПДн и матрицы доступа, в конце концов - эти работы все равно придется проводить. Стоит подумать о том нужно ли нам брать согласие на обработку персональных данных с сотрудников и с клиентов - возможно, это облегчит нам жизнь. Например, если водители не дадут согласие на обработку своих ПДн для печати доверенностей - тем лучше, будут вписывать паспортные данные самостоятельно, а мы уберем десяток рабочих мест из ИСПДн.
В общем, думаю, что теперь мне будет чем заняться на работе - время и деньги потрачены не зря. Знания систематезированы, какой-то порядок в голове появился - это хорошо.

Неопределенность. Часть 2.

Только что закончился очередной день, проведенный на курсах по защите персональных данных.
Сегодня было, как обычно, два преподователя.
Первый из них уже читал лекции и его точка зрения на обязательность применения СТР-К в коммерческих ИСПДн (этот вопрос, в итоге я задал всем преподователям) уже была известна - не надо. С ним мы разбирали 781-е постановление и 58-й приказ. Не могу сказать, что узнал что-то новое, но повторение - мать учения, так что я не думаю, что зря провел время. Более того, было несколько интересных моментов.
Во-первых, действительно, разница между вторым и третьим классом ИСПДн минимальна. Фактически, все сводится к тому, что для второго класса чуть больше требований к МСЭ (при условии подключения ИСПДн к Internet) и необходимость использования оборудования, имеющего сертификат на электромагнитную совместимость. Для третьего класса такого требования нет. Это действительно мелочи.
Во-вторых, он объяснил в чем различие классов автоматизированных систем по СТР-К. Не могу сказать, что это очень полезно, но довольно-таки интересно.
После этого пришел новый преподователь, которому я, естественно, задал тот же вопрос про СТР-К. Ответ был: не обязаны, поскольку в самом СТР-К написано, что для коммерческих информационных систем этот документ носит рекомендательный характер. Это логично, но двое из четырех преподователей говорят, что все равно СТР-К обязателен для применения в ЛЮБЫХ системах.
С ним мы быстро пробежали 19-ю статью 152 ФЗ и постановления 781 и 687. Больший упор в его лекциях делается на обработку ПДн без использования средств автоматизации и на утечку "речевых" ПДн и по техническим каналам.
Что интересно - он признает, что выполнение всех подзаконных актов не гарантирует выполнения закона "О персональных данных", поскольку все эти подзаконные акты были написаны по предыдущей версии закона, но, по его же словам - пока нет новых актов (которые вроде как уже готовятся, но когда будут еще неизвестны) - проверки будут проходить на соответствие подзаконным актам, существующим сейчас. Т.е., занимать выжидательную позицию и ждать чем все закончится, он не советует. Но и классификацию проводить он не рекомендует, как и выполнять требования из 58-го приказа. Т.е., его позиция - нужно проводить обследование, составлять модель угроз и закрывать актуальные угрозы сертифицированными средствами, исходя из положений положения 781.
Из того что было особенно интересно, из его выступления:

• ФСТЭК закрывает глаза на отсутствие лицензии на ТЗКИ, при проведении работ "для себя";
• коммерческим ИСПДн не требуется аттестация;
• государственным ИСПДн требуется аттестация, при любом классе ИСПДн - это требование СТР-К.

Таким образом, лично для меня, все становится еще более запутанным.

Неопределенность

Второй день занимаюсь на курсах повышения квалификации по защите персональных данных.
Программа курса, как говорят, преподаватели, согласована со ФСТЭКом, однако, по этой программе у меня есть определенные вопросы.
Точнее, не по самой программе, а по тому что нам дают. Всего этот курс читают четверо преподавателей - трое из них часть своего материала уже отчитали, четвертый появится завтра. Что любопытно - у всех троих свой взгляд на этот закон. Один из них говорит, что СТР-К и другие документы, посвященные конфиденциальным данным, может быть удобно использовать при создании документации к ИСПДн (СЗПДн), но обязательный характер эти документы не носят. Такая позиция мне понятна и очень даже нравится - в этом случае мы не обязаны составлять технические паспорта на компьютеры и проводить аттестацию системы.
Другой говорит, что ВСЕ операторы ОБЯЗАНЫ использовать СТР-К и, соответственно, проводить аттестацию системы, составлять технические паспорта и прочее. Но, опять же, он не говорит о том как проводить параллели между классом ИСПДн и классом АС, но признает, что это разные вещи, т.е. остается неопределенность - какие требования СТР-К мы должны выполнять для ИСПД класса К2, например.
Третья точка зрения - ВСЕ документы ВСЕХ регуляторов в части конфиденциальных данных обязательны для применения. Т.е. в первую очередь мы защищаем конфи, а только потом персональные данные.
Вот как, блин, как они все это согласовали со ФСТЭКом? Или ФСТЭК считает, что любой из этих подходов имеет право на жизнь и оператор сам должен выбирать? В таком случае, мне кажется, должна быть оговорка, что оператор волен выбирать любой из понравившихся вариантов.
Впрочем, до конца курсов еще далеко и, возможно, что-то прояснится.
На данный момент, самое главное, что я вынес с курсов (и в чем сходятся все преподаватели) - это то, что для работ по установке, настройке и вводу в эксплуатацию средств защиты информации, организация должна иметь лицензию по ТЗКИ от ФСТЭК. Если такой лицензии нет - мы обязаны приглашать лицензиата (это, кстати, хорошо объясняет почему четверть стоимости по коммерческому предложению одного из лицензиатов - это именно работы по настройке СЗИ). Тут есть один нюанс, все они говорят, что готовится к принятию новый закон о лицензируемых видах деятельности, в результате принятия которого, лицензия на ТЗКИ будет "разбита" на несколько более мелких лицензий, что может облегчить и удешевить для оператора процесс получения такой лицензии.
Еще один важный момент - использование ТОЛЬКО сертифицированных СЗИ. Фактически, слов "сертифицированные СЗИ" в законе и подзаконных актах нет, но пункт 5 положения об обеспечении безопасности персональных данных при их обработке в ИСПДн, говорит о том, что СЗИ, применяемые в ИС, в установленном порядке проходят процедуру оценки соответствия.
Фактически, под процедурой оценки соответствия подразумевается та самая сертификация, и, если у СЗИ, применяемого у нас, нет сертификата, мы можем не заменять его, а договориться с одним из аттестационных центров (список которых есть на сайте ФСТЭК) о проведении процедуры оценки соответствия для этого СЗИ. Что будет стоить, вероятно, бешенных денег, но в итоге у нас будет сертифицированное СЗИ. Ход, по сути, достаточно глупый (на мой взгляд) и дорогостоящий, т.е. лучше сразу проектировать СЗПДн с теми СЗИ, которые уже имеют сертификат соответствия требованиям ФСТЭК.
Плюс, было много ссылок на 149 ФЗ, с которым я, увы, пока не успел познакомиться - возможно, после ознакомления что-то для меня прояснится.

Гениальное

Где это все сейчас? Где?!

Ненависти псто

Вот казалось бы, что может быть проще - записаться на курсы... Ан нет, все не так просто.
Маленькая предыстория.
В связи с принятием гениального 152-го федерального закона "О персональных данных" в далеком 2006 году, жизнь операторов персональных данных стала прекрасной и удивительной. Во-первых, операторами персональных данных являются абсолютно все организации - ОАО, ЗАО, ИП, ПБОЮЛ, вообще все, у кого есть сотрудники, либо контрагенты - физические лица. Во-вторых, денег, для приведения информационной системы персональных данных, в соответствие этому чудесному закону, требуется чуть больше чем до хрена, а сложность администрирования получившиейся системы возрастает если не на порядки, то в разы уж точно. Ну, это небольшое отвлечение от темы. В общем, есть закон, который мы обязаны соблюдать.
По воле рока так случилось, что отвественным за исполнение этого закона был назначен я. Естественно, я не единолично решаю как будет защищаться предприятие - в этом принимает участие весь отдел. Но если придет проверка и вскроется, что мы не защищены, то штраф, по словам юристов, наложат на меня и, если я в какие-то сроки, не приму меры, мне даже могут запретить занимать должности связанные с защитой информации (и, видит Бог, я не буду переживать по этому поводу). Но я опять отвлекся.
В общем, поскольку нас хотят защищать аж 4 фирмы, но у каждой из этих фирм своя точка зрения на защиту ПДн, выбрать очень тяжело. Хотя бы потому, что я (и никто из отдела, в общем-то) вообще нихрена не понимаю как в итоге должна выглядеть защищенная система. И было принято волевое решение отправить меня на курсы.
Сказано-сделано. Нашли курсы в Омске. В ОмГТУ. Программа вроде нормальная, но по телефону не смогли сразу назвать фамилию того кто их ведет. Ладно, хрен с ним, по крайней мере хоть кому-то можно будет задать вопрос, может быть даже с кем-то пообщаться на тему - как это сделано у них и что они обо всем этом думают. Обменяться опытом, так сказать.
Итак, созваниваюсь и говорю, что хочу пройти курс "Защита персональных данных". "Отлично!", говорят мне. "Как раз 28-го ноября начинается такой курс. Народу правда мало, но он точно будет". В тот же день, мне высылают проект договора, мы подписываем его и мы договариваемся, что 28-го числа я приношу подписанный нами договор к началу занятий.
Договор я принес, но, блядь, когда начались занятия, оказалось, что это ДРУГОЙ курс.
Другой, блядь. Вот как это вообще возможно? Курс не по защите персональных данных, а по криптографической защите информационных систем.
Криптография мне не уперлась вообще никуда, курс по защите персональных данных есть, но он занятия там начались неделю назад. Договор заключался на прохождение мной курса по защите персональных данных. И ведет оба курса давний знакомый, бывший сотрудник одной из фирм-лицензиатов ФСТЭК. Мужик, конечно, умный, но точки зрения наши во многом не совпадали.
В общем, завтра буду звонить в полутех и ругаться-ругаться-ругаться.
Завтра же будет подтверждена, либо опровергнута бритва Хэнлона: "Не стоит искать злого умысла в том, что может быть объяснено человеческой глупостью". Может быть действительно, тетушка на телефоне не видит разницы между этими двумя курсами?! Не понимаю...

upd


Ну вот и завершение этой глупой истории.

Поскольку на курс по защите персональных данных записалось 3 человека и на курс по криптографической защите информационных систем записалось столько же человек - в чью-то, без сомнения гениальную, голову пришла идея эти курсы совместить.
Что интересно. Программа курса для всех будет одна, но корочки все получат разные. Трое, как и планировали - по защите ПДн, другие трое - по криптографической защите ИС.
Немного удивила позиция преподователя: "Если он такой умный, то зачем записался на курсы?", высказанная в личном разговоре между ним и моим начальником.
Я, блядь, не считаю себя "таким" умным, но хочу разобраться как и что надо делать, а не сидеть с вылупленными глазками и внимать бреду льющемуся из его рта.
Ни один, ни один человек не смог доказать мне, что
1) нашу ИСПДн надо аттестовывать;
2) при защите ИСПДн надо руководствоваться, в том числе, СТР-К.
В общем, я несколько растроен, был лучшего мнения об этом человеке и думал, что он так же хочет и может разобраться в хитросплетениях 152 ФЗ.

Чудеса с журналом регистрации в 1С 8.2.13.205

В конце мая пришлось столкнуться со следующей проблемой.
После того как все пользователи выйдут из одной из информационных баз 1С (по причине обновления, перезапуска службы, перезагрузки сервера, либо просто все закончили работу и отправились по домам), подключение к этой же базе 1С занимало неоправданно долгое время - 3-5 минут. Потом, спустя эти самые 3-5 минут, наконец появляось окно для ввода логина и пароля, и никаких проблем в дальнейшем пользователи не испытывали. До тех пор пока все снова не выйдут из 1С. После этого ситуация повторялась. При этом, проблема возникала только на одной, основной, информационной базе. Из других баз пользователи могли входить и выходить когда им удобно, "злополучное" окно появлялось моментально.
В качестве временной меры было выбрано такое решение - на моем компьютере, включенном постоянно, 1С не закрывалась никогда. Если мне тоже требовалось выйти из 1С, чтобы программисты могли обновиться - у нас была договоренность - до тех пор пока три человека не войдут в эту ИБ, они не закрывают конфигуратор. Естественно, это не избавляло нас от всех проблем. Во-первых, программисты могли забыть об этом и закрыть конфигуратор, во-вторых, сервер 1С "любит" перезагрузки. Увы, но это так, если не перезагружать его длительное время, начинаются непонятные тормоза в произвольные моменты времени у произвольных пользователей (к серверу СУБД это не имеет никакого отношения). Соответственно, время этих процедур увеличивалось на 5 минут, что было совершенно неприемлимо. С одной стороны, если бы это была какая-нибудь редкоиспользуемая ИБ, никто даже не обратил бы на это внимания, но именно для этой базы требовалось обеспечить максимальную скорость работы.
Тогда, в мае, я обратил внимание на следующее: на любой копии базы, на любом сервере (как тестовом, так и на рабочем) проблема не появляется. При этом, процесс rmngr.exe (Менеджер кластера сервера 1С) потреблял 25 процентов процессорного времени, т.е. фактически захватывал одно ядро, на все 5 минут, которые длилось ожидание. После того, как он переставал "жрать" процессор, работа возобновлялась в нормальном режиме.
Зная, что у 1С возможны проблемы с "локальным кэшем", я предположил, что серверный кэш так же может быть причиной проблемы. Однако, ни удаление всех "временных" папок, создаваемых 1С, ни удаление каталога snccntx, ни запуск сервера 1С под другим пользователем, ни даже полная переустановка платформы не приносили никакого результата. В результате, я удалил информационную базу с сервера 1С и создал ее под другим именем. И, о чудо, проблема решилась.
Прошло 4 месяца.
Возникла та же самая проблема. Программисты "выгнали" всех из 1С для проведения обновления, а когда работу можно было продолжить - оказалось, что войти в эту самую информационную базу, никто не может. Окно с предложением ввести логин и пароль появилось только через 5 минут...
В этот раз, я твердо знал, что "пересоздание" информационной базы на сервере 1С поможет железно, но решил, что это решение не отличается ни простотой, ни красотой и следует найти что-нибудь более удобное. В первую очередь задумался: в чем разница между новой информационной базой и старой, при условии, что сама база данных на сервере СУБД остается нетронутой. И единственное различие, которое я увидел - это журнал регистрации.
Да, журнал регистрации, в который могут записываться ошибки, предупреждения и просто все действия пользователей. У нас, это было известно точно, в журнал регистрации писалось все возможное и еще немного сверху. В то время когда мы принимали участие в проекте ЦКТП, программисты добавляли в журнал регистрации записи о времении выполнения самых важных для предприятия процедур. После завершения проекта было решено, продолжать записывать эти данные, поскольку по ним можно увидеть как себя ведет система с течением времени.
Заглянув в каталог журнала регистрации (по адресу C:\Program Files\1cv82\srvinfo\reg_1641\id_базы\ - чтобы узнать id_базы посмотрите содержимое файла 1CV8Reg.lst) я увидел два каталога: 1Cv8FTxt и 1Cv8Log. Первый из которых содержал кучу файлов (период разделения ЖР установлен в "день") с совершенно нечитаемым содержимым, а второй содержал вполне привычные файлы журнала регистрации с расширениями .lgf и .lgp.
Итак, поскольку, я решил, что проблема найдена, в Конфигураторе был выбран пункт меню Сервис->Настройки журнала регистрации и нажата кнопка "Сократить". Я сохранил сокращаемые записи ЖР в папку и решил, что проблема решена. Увы, это оказалось не так. Суммарный размер файлов журнала регистрации составлял 900 мегабайт до сокращения и 450 мегабайт после его сокращения. Казалось бы, минимум в два раза время ожидания должно сократиться. Но нет, время не уменьшилось, совсем.
Готовясь плюнуть на все и "пересоздать" ИБ на сервере 1С, я, для успокоения совести, решил скопировать папки с ЖР на тестовый сервер, в идентичную базу и посмотреть что из этого получится. Как только копирование завершилось, я решил войти в эту ИБ конфигуратором - и, вот здесь произошло второе чудо, не смог. Тестовый сервер жалобно пыхтел одним ядром, а я любовался на белый квадрат в середине экрана. Окна с предложением ввести логин и пароль, не было. Спустя 35 минут окно появилось, конфигуратор открылся, rmngr.exe снова потреблял не больше 1-2 процентов процессорного времени.
Таким образом, было очевидно - причина в журнале регистрации. Однако, уменьшение его в размере совершенно не помогало. Тут произошло третье чудо - я вспомнил про чудесную утилиту FileMon от Марка Руссиновича. Оказалось, что такого продукта больше не существует, а его место занял ProcMon, совмещающий в себе функционал как FileMon, так и RegMon. Скачать его можно здесь.
Первым делом, нужно настроить фильтр, поскольку на работающей операционке каждую секунду производятся десятки и сотни вызовов к реестру, файловой системе, сети и другим ресурсам. В первую очередь я создал правило, исключающее всю информацию о процессах, имя которых отличается от "rmngr.exe" и еще одно правило, отсекало все записи, в которых путь не содержал в себе "C:\Program Files (x86)\1Cv82\" (это каталог в который устанвливается 32-х разрядная серверная и клиентская части 1С на 64-битной ОС).
И вот что я увидел:

Процесс rmngr.exe медленно и грустно "пережевывал" файл 1Cv8.lgf в папке журнала регистрации. Самое удивительное для меня заключалось в том, что размер файла был очень и очень небольшим - 11 мегабайт.
Когда rmngr.exe закончил с этим файлом, я вошел в режиме Конфигуратора и снова сократил журнал регистрации. Каково же было мое удивление, когда я увидел, что из папки журнала регистрации удалились файлы .lgp до той даты которую я выбрал, а вот файл 1Cv8.lgf остался нетронутым!
И, естественно, при следующей попытке запуска конфигуратора, rmngr.exe снова "прочесывал" весь 1Сv8.lgf. Методом научного тыка было выяснено:

• если сокращать журнал регистрации до определенного момента в прошлом, файл 1Cv8.lgf, проверяемый процессом rmngr.exe, не изменяется в размерах;
• если сокращать журнал регистрации на сегодняшний день, 1Cv8.lgf не изменяется;
• если выбрать дату завтрашнего дня - бинго! файл 1Cv8.lgf очищается.

Естественно, при выборе последнего (да и второго варианта) информационная база, фактически остается без журнала регистрации (т.е. встроенными средствами через Сервис->Журнал регистрации) его нельзя будет просмотреть, поэтому требуется, при сокращении, ЖР сохранять его в папку, доступ к которой должен быть у всех пользователей, работающих с журналом регистрации.