Governance as a code что это

Вы отправили слишком много запросов, поэтому ваш компьютер был заблокирован.

Для того, чтобы предотвратить автоматическое считывание информации с нашего сервиса, на Linguee допустимо лишь ограниченное количество запросов на каждого пользователя.
Пользователям, браузер которых поддерживает Javascript, доступно большее количество запросов, в отличие от пользователей, чей браузер не поддерживает Javascript. Попробуйте активировать Javascript в настройках вашего браузера, подождать несколько часов и снова воспользоваться нашим сервером.
Если же ваш компьютер является частью сети компьютеров, в которой большое количество пользователей одновременно пользуется Linguee,сообщитеоб этом нам.

Враг не пройдёт, или как помочь командам соблюдать стандарты разработки

Подход governance as a code обеспечивает контроль соблюдения архитектурных принципов как в части конфигураций инфраструктуры, так и в части программного кода. Правила проверки каждого артефакта, будь то конфигурация k8s, список библиотек или даже описание сценария CI/CD, описаны специальным кодом проверки правил, имеют свой жизненный цикл, могут тестироваться и ничем не отличаются от обычного программного продукта.

Александр Токарев (Сбербанк) расскажет, как и что можно проверять в процессе разработки программного обеспечения, чтобы разрабатывать более безопасные и качественные приложения, и почему Сбербанк решил не использовать такие очевидные решения как SonarQube, а разработать собственное решение на базе Open Policy Agent без дополнительных пакетов над ним. Также Александр покажет, когда выбирать admission controller, когда использовать «чистый» Open Policy Agent, а когда можно обойтись без какого-либо контроля.

Александр поговорит о том, нужны ли стандарты, что такое язык Rego и что за крутой продукт Open Policy Agent, а также рассмотрит нетиповые кейсы его применения, как с ним работать, и как его использовать для контроля. Email Александра.

Итак, представьте Сбербанк:

Более 50 приложений в облачной платформе OpenShift в production;
Релизы не реже двух раз в месяц, а порой и чаще;
Ожидается не менее 20 новых приложений в год для перевода в Openshift;
И все это на фоне микросервисной архитектуры.

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

План перехода к автоматизации

Базовые проверки;
Интеграция с контролем версий;
Повторное использование проверок;
Автоматическое применение проверок;
Коррекции на основе проверок;
Продвинутые проверки – когда вы всему научились и можете писать очень крутые вещи.

Базовые проверки

Google предлагает начать их с Kubernetes и приводит нас к абсолютно старым и неживым проектам:

Можно обнаружить живые и развивающиеся проекты, но при их изучении понимаешь, что для результата надо написать очень много букв с точки зрения CRD, они жёстко прибиты к Kubernetes, у них нет DSL (потому что сложные проверки описываются через REGEXP), и при этом нет возможности дебага политик. Вот пример DSL такого продукта, который проверяет CPU и memory limit в кластере. Это абсолютно своя CRD, которая выводит обычное сообщение, и далее нужно много букв и REGEXP для того, чтобы это контролировать:

Можно взять Sonar, но мы поняли, что для создания в нём элементарного правила нужно минимум 7 артефактов, а это довольно сложно:

После долгих поисков мы обнаружили замечательный продукт — Open Policy Agent (OPA), который на самом деле движок политик, написанный на Go. Он очень быстрый, потому что inmemory. Им можно проверять всё что угодно с использованием собственного декларативного языка Rego, который не сложнее SQL. Можно использовать внешние данные и встраивать продукт куда угодно. Но самое главное — мы можем управлять форматом ответа, когда это не просто boolean true/false, а всё, что мы захотим увидеть.

Простейшая проверка, проверяющая заполнение ревестов и лимитов, включает в себя получение всех контейнеров Kubernetes, которые объявлены в нашем YAML, их проверку на заполнение нужных полей (проходя по структуре YAML) и вывод сообщения (JSON). Если с проверкой всё хорошо, то в result не будет ничего. Три строчки кода — и у вас она работает:

Конечно, объекты на продакшене гораздо более сложные, потому что надо что-то фильтровать, надо всё также получать списки контейнеров и работать с состоянием целого кластера. Дополнительно мы выводим диагностическое сообщение о том, пройдена или нет проверка, статус её прохождения, вид проверок (группа) и фактически тот объект, который тестировала проверка.

Примеры проверок K8S

Maven;
NPM;
Terraform;
Даже ER diagrams, потому что в том же Power Designer это XML.

Есть Open Policy Agent и есть система плагинов на Python (потому что на нем элементарно написать преобразования) и конечно же пользовательский интерфейс. Таким образом проверка абсолютно любой конфигурации (K8S YAML, Pom.xml, .properties, .ini) работает просто.

Наш интерфейс при этом тоже очень простой и удобный: мы можем подать ему список данных для тестирования или список REGO проверок, выполнить проверку и легко увидеть, что выполнилось и что нет. Есть очевидные «вкусности» — фильтрация, сортировка, выгрузка. Абсолютно все просто, понятно и красиво:

Вернемся к примеру maven:

Предположим, мы хотим контролировать использование spring-boot-starter-actuator для написания тех самых readinessProbe. Живая проверка очень проста: мы получаем все dependency, а дальше смотрим, что библиотека — это spring-boot-starter-actuator. Как я уже говорил, большая часть проверок — это вывод диагностических сообщений об их прохождении/непрохождении:

Однако бывают более сложные кейсы. Предположим, нам нужно проверить конфигурацию Kubernetes на наличие разрешённых image (fluentbit2, envoy3, nginx:1.7.9) и вывести имя запрещённого. Видим, что у нас есть валидная конфигурация с абстрактным nginx и есть конфигурация с запрещённым nginx:

Поищем в Google как это сделать. Само собой, первая ссылка приводит на сайт проекта, но, как принято в документации OPA, там нет информации о том, что нам надо:

Воспользуемся ссылкой от Amazon, они же профессионалы! Большой код, 19 строк букв — где та самая лаконичность, которую я вам рекламировал раньше? Какие-то непонятные команды, палки — что это? Долго-долго читаем документацию, понимаем, что это так называемый Object comprehension, и что на самом деле коллеги из Amazon транслируют массив как есть в список объектов. Почему? Потому, что из документации непонятно, что можно объявить объект таким элементарным и очевидным образом:

Тем не менее применяем и получаем результаты. Но всё равно очень много букв — 13 строк кода!

А как же написать, чтобы было красиво, и чтобы пользоваться всей мощностью декларативности? На самом деле все очень просто: получаем контейнер Kubernetes, а дальше представляем, что у нас SQL и фактически данными строчками пишем not in. Мыслите в терминах SQL, будет гораздо проще. За 7 строчек кода мы получаем действительно нужную нам информацию — все неразрешённые контейнеры name:

Где все это писать? Есть две тулзы:
Rego Playground
Она размещена в интернете авторами продукта и позволяет вести отладку онлайн. Она не всегда хорошо выполняет сложные проверки, но самое ценное её свойство для меня — готовая библиотека проверок, где можно подсмотреть какие-то идеи:

Плагин Visual Studio Code
Действительно прекраснейший плагин. В нем есть всё, что надо для средств разработки:

Syntax check – проверка синтаксиса;
Highlighting – подсветка;
Evaluation – вычисления проверок;
Trace – трассировка;
Profile – профилирование;
Unit tests – запуск юнит-тестов

Интеграция

Push-интеграция, когда через REST API помещаем наши проверки и внешние данные в Open Policy Agent:

curl -X PUT localhost:8181/v1/data/checks/ —data-binary @check_packages.rego
curl -X PUT localhost:8181/v1/data/checks/packages —data-binary @permitted_packages.json

Pull-интеграция — OPA bundle server, которая мне очень нравится.

В соответствии с конфигурацией Open Policy Agent сервер умеет ходить в bundle-сервер по фиксированному урлу и забирать данные, если они ещё не подготовлены. Далее он ожидает их приема в .gzip формате, полностью поддерживая спецификации кэширования — если вы в bundle-сервере реализовали обработку тэга ETag, то Open Policy Agent сервер не будет протаскивать мегабайты ваших проверок через сеть в случае неизменения:

Выполняем проверку. Open Policy Agent имеет прекрасный resfull API — после загрузки наших данных мы получаем имя пакета, который мы создали при создании файла, и имя правила. Дальше мы подаём для проверки наш артефакт в виде JSON. Если вы долго читали документацию, то поняли, что наш артефакт надо обрамить в input:

Обрабатываем результат (возвращённый JSON) где угодно — в Jenkins, admission controller, UI, whatever… Чаще всего результат приходит в таком виде:

Повторное и автоматическое использование проверок

Политики OPA у нас разработаны для тех проверок, которые не связаны с Kubernetes, и тех, что связаны с Kubernetes, но рекомендуются. Они хранятся в гите и через наш Bundle server, как и метаданные, попадают в Open Policy Agent. Мы пользуемся встроенными механизмами Open Policy Agent для Unit-тестирования и тестируем все наши проверки.

То есть Open Policy Agent проверяет сторонние артефакты (Java configs, K8S config, артефакты CI/CD), а те, которые надо заблокировать для попадания на кластеры, проходят через Gatekeeper, и в итоге наш кластер в безопасности. В принципе мы можем проверять всё что угодно, и смотреть результаты проверок через наш пользовательский интерфейс:

У нас есть 24 обязательных правила и 12 необязательных;
80 правил планируется к использованию в данном продукте;
Автоматическая проверка одного проекта за 10-20 секунд.

Коррекции на основе проверок

По безопасности (Security inventory): Roles, Rolebindings, Clusterroles, Clusterrolbindings;
По управлению ресурсами (Capacity Inventory): cpu, memory через ResourceQuotas и LimitRange;
По управлению дисками (NFS inventory): Persistent volumes и Persistent volume claims.

Pull измененных политик и данных из гита и inventory через bundle-сервер;
Создание объектов в K8S на основе данных, создаваемых OPA;
Hand-made mutating admission controller — на основе JSON, возвращенного OPA, формируется YAML и прогоняется на кластере:

Go routine and thread counts;
Memory in use (stack vs heap);
Memory allocated (stack vs heap);
GC stats;
Pointer lookup count;
Roundtrip time by http method;
Percentage of requests under 500ms, 200ms, 50ms;
Mean API request latency;
Recommendations for alerting;
Number of OPA instances up at any given time;
OPA responding under 200ms for 95% of requests.

24 проверки;
1 Mb справочных данных по безопасности — 3500 правил;
2 Mb справочных данных по дискам и ресурсам — 8000 правил;
Применение правила на кластере — от 2 до 5 минут — реально очень быстро.

Продвинутые проверки

Если мы хотим писать крутые, навороченные проверки, что же делать? Есть несколько способов — взять готовое или стать ещё более крутым.

Fugue

Мы можем использовать Fugue, который представляет движок политик как сервис (governance as a code as a service). Он проверяет конфигурации облаков Amazon, Azure, GCP. Представляете, насколько там сложные политики, что ему надо проверять не только Kubernetes, но и relational database services, VPC и т.д.? Фактически каждый из продуктов каталога Amazon и прочих облаков может быть проверен готовыми политиками.
Fugue работает как admission controller. Ещё одна из очень его больших ценностей — это наборы пресетов под регуляторы — PSI DSS, HIPAA, SOC, etc. Фактически вы делаете нужную инфраструктуру в Amazon, запускаете продукт и говорите: «Проверь на PSI DSS», — и вуаля, вы получаете фактически аудит.

Очевидно, что Fugue реализован на OPA, но так как политики очень сложные, коллеги реализовали свой интерпретатор Rego для отладки продвинутых проверок. Выполнение происходит на Open Policy Agent, а отладка уже на своем интерпретаторе. Так как это облачный продукт, у него прекраснейший пользовательский интерфейс, который позволяет понять, какие проверки пройдены, какие нет и процент их соответствия:

Набор правил действительно самый разнообразный — есть элементарнейшие вещи в стиле «на машине с RDS, если она гарантирует высокую доступность, должны быть использованы multi availability zone deployment»:

И есть гораздо более сложные, например, «если используется Elasticsearch от Amazon, то его пользовательский интерфейс не должен быть выставлен наружу»:

С Fugue можно ознакомиться на их сайте. Но гораздо интереснее их интерпретатор Rego и набор примеров, которые у них реализованы.

Fregot

Fregot — это очень живой продукт, который позволяет отлаживать проверки на Rego. За счет чего? У него упрощённый дебаг (breakpoints и watch variables) и расширенная диагностика по ошибкам, которая важна, когда вы будете пользоваться ванильной OPA — в этом случае чаще всего вы будете получать сообщение: var _ is unsafe, и вам будет абсолютно непонятно, что с этим делать:

Conftest

Это утилита проверки, использующая Open Policy Agent. Она содержит в себе потрясающе огромный встроенный набор конвертеров, и сама выбирает конвертер, исходя из расширения файла:

Ещё раз обратите внимание, насколько выразительный язык Rego — всего одной строкой мы проверяем, что нельзя запускать контейнер из-под root:

Дальше мы говорим: «conftest test», и указываем имя того объекта, который нам надо протестировать. И все проверки, которые есть в директории утилиты, проверяются по файлам, а вы получаете результат.

Большое количество конверторов файлов: YAML, INI, TOML, HOCON, HCL, HCL1, CUE, Dockerfile, EDN, VCL, XML.
Много примеров проверок при работе с Open Policy Agent.

Не могу сказать, что утилита стабильно работает
Так как эта утилита командной строки, то она однопоточная, на продакшн ее не так круто применять.

Gatekeeper

Сейчас это Admission controller, а в будущем он будет работать как Mutating admission controller, который не только проверяет на условие, но и в случае прохождения условий меняет команду так, как ему надо:

Admission controller встает между вашими командами и кластером Kubernetes. Вы отправляете команду, admission controller вызывает внешнюю проверку условий и, если условие выполнено, то команда запускается в кластере. Если не выполнено, то команда просто откатывается.

Policy Template – это механизм описания функций, где вы задаете текст проверки на Rego и набор входных параметров;
Сама политика – это вызов функции с указанием значений параметров.

Пример проверки на Gatekeeper:

Это своя CRD, само собой. Мы даем ей имя и говорим, что входной параметр – это метки, которые представляют собой массив строк. Пишем на Rego нашу проверку, и в данном случае она проверяет, что для объектов заданы необходимые метки. Мы используем внутри Rego наши входные параметры — это тот самый template. А живая политика выглядит так: используй такой-то template и такие-то метки. Если у проекта не будет таких меток, то он просто в кластер не попадёт:

Великолепно работает повторное использование через template;
Есть огромные готовые библиотеки проверок;
Тесная интеграция с K8S.

Нельзя запустить Gatekeeper без K8S;
Нет юнит-тестов констрейнтов и темплейтов;
Многословные CRD;
Нет UI (пользовательского интерфейса);
информацию для аналитики приходится получать через парсинг логов;
Закрыта возможность вызова внешних сервисов;
Нельзя использовать bundle server для помещения в него внешних данных;
Функционал Mutation в процессе разработки, о чем регулярно напоминают разработчикам в их гите.

Что мы получили на выходе

Итак, фактически мы преобразовали уровни зрелости технологического контроля к готовому технологическому стеку:

OPA на практике — use cases

Как мы увидели, Open Policy Agent решает задачи проверки любых структурированных данных, а также коррекции проверенных данных. Хотя на самом деле Open Policy Agent позволяет делать гораздо больше, например, помогает решать задачи авторизации, задачи database row level security (sql databases, ElasticSearch), а некоторые даже пишут на нём даже игры (Corrupting the Open Policy Agent to Run My Game).

Рассмотрим несколько примеров.

OPA as a sidecar

У коллег в Pinterest всё развернуто в Amazon, поэтому у них принят подход Zero-trust security и, само собой, все реализовано на OPA. Под его контролем находится всё, что связано с Kubernetes, с виртуальными машинами, авторизацией в Kafka, а также с авторизацией на Envoy.

Таким образом их нагрузка колеблется от 4.1M до 8.5M QPS в секунду. При этом имеется кэш с длительностью жизни 5 минут. В Open Policy Agent приходит от 204 до 437 тысяч в секунду запросов — действительно большие цифры. Если вы хотите работать с такими порядками, надо конечно думать о производительности.

Network footprint — подумать о тех нюансах, которые приносит сеть.
OPA library single-thread — если вы используете Open Policy Agent не как сервер, а как библиотеку, то библиотека будет однопоточной.
Use OPA server instead – multi-thread — вам придется делать многопоточность вручную.
Memory for data – 20x from raw data — если у вас есть 10 МБ внешних данных каких-нибудь JSON-справочников, то они превратятся в 200 МБ на сервере.
Partial evaluation – ms to ns — вам надо разобраться, как работает его фишка механизма предрасчета, фактически компилирование статической части проверок.
Memory for partial evaluation cache — вам надо понимать, что для всего этого требуются кэши.
Beware arrays — с массивами Open Policy Agent работает не так хорошо.
Use objects instead — и именно поэтому коллеги с Amazon транслировали массивы в объекты.

Очень интересно, как происходит у них доставка политик. Есть кластер, есть Bitbucket, а дальше данные из него хуками на коммит пробрасываются на S3. Так как запись в него асинхронна в принципе, то результат идет в Zookeeper, а он уведомляет Sidecar об изменениях. Sidecar забирает данные из S3, и всё прекрасно:

OPA authorization

Задачи авторизации становятся все более актуальными, и все больше разработчиков получают запросы, чтобы включить Open Policy Agent в их продукты… Многие уже это сделали: например, Gloo в своей энтерпрайз-версии использует Open Policy Agent как движок для авторизации.

Но можно это сделать по-другому. Наверное, все знают, что такое Envoy. Это легковесный прокси, в котором есть цепочки фильтров. Envoy крут тем, что позволяет обеспечивать дистанционное управление конфигурацией. Собственно, отсюда и появился термин service mesh:

На Envoy мы можем опубликовать Open Policy Agent сервер снаружи и настроить так называемые фильтры внешней авторизации. Далее любой запрос от пользователя вначале попадает на Envoy, проверяется им, и только после этого отправляется наружу:

Penetration testing

На самом деле авторизация — это всегда о безопасности. Поэтому в 2018 году было проведено Penetration-тестирование: 6 человек в течение 18 дней пытались взломать Open Policy Agent. Результаты тестирования говорят, что OPA — это действительно безопасное решение:

Конечно, были ошибки:

Identified Vulnerabilities
OPA-01-001 Server: Insecure Default Config allows to bypass Policies (Medium)
OPA-01-005 Server: OPA Query Interface is vulnerable to XSS (High)
Miscellaneous Issues
OPA-01-002 Server: Query Interface can be abused for SSRF (Medium)
OPA-01-003 Server: Unintended Behavior due to unclear Documentation (Medium)
OPA-01-004 Server: Denial of Service via GZip Bomb in Bundle (Info)
OPA-01-006 Server: Path Mismatching via HTTP Redirects (Info) Conclusions Introduct

Но это были те ошибки, которые случаются по большей части от того, что есть проблемы с документацией:

What is more, the shared documentation was unclear and misleading at times (see OPA-01-001), so that arriving at a secure configuration and integration would require a user to have an extensive and nearly-internal-level of knowledge. As people normally cannot be expected “to know what to look for”, this poses a risk of insecure configurations.

OPA – не экзотика

Юнит-тестирование;
Трейсинг, профайлинг и бенчмаркинг;
Механизмы ускорения производительности Conditional evaluation;
Возможность обращения к внешним http-сервисам;
Работа с JWT-токенами.

Идем по первой же ссылке и попадаем всего лишь в функцию, которая выводит отладочную информацию, не имеющую никакого отношения к тому, как же политика выполняется:

Но если поковыряться с утилитой repl, которая входит в состав OPA, абсолютно случайно можно найти функцию trace, про которую, конечно же, ничего не сказано в документации. Именно она фактически показывает план выполнения проверки, с которым очень легко работать и отлаживаться:

Open Policy Agent находится под крылом CNCF, и он более чем живой. В итоге хотелось бы сказать, что да, по данному продукту сложно найти информацию даже в объемной и неоднозначной документации. Но продукт активно развивается, живет не только в контейнерах, его можно использовать в абсолютно разных кейсах. И он действительно безопасен, как показали Penetration-тесты.

Если вы хотите его использовать, вам придется создавать UI и научиться писать правила на языке, близком к естественному, а не на языке кода. Учите Rego и используйте Fregot для дебага.

Помните, что Гугл, скорее всего, вам не поможет.

Тем временем мы готовимся к конференции HighLoad++, которая состоится офлайн 9 и 10 ноября в Москве (Сколково). Это будет наша первая очная встреча после 9 месяцев онлайнового общения.

HighLoad++ — это 3000 участников, 160 докладов, 16 параллельных треков докладов, мастер-классов и митапов. Единственная конференция, где за два дня можно узнать, как устроены Facebook, ВКонтакте, Одноклассники, Яндекс, Mail.ru, Amazon, Badoo, Авито, Alibaba и другие крупнейшие компании.

А в этом году главная задача HighLoad++ — выяснить пределы технологий. Как обычно, каждый доклад будет о решении конкретной задачи.Если есть что-то достойное в мире технологий, то это точно будет на HighLoad++ 🙂

Новости и подборки докладов мы публикуем в рассылке и в telegram-канале @HighLoadChannel — подпишитесь, чтобы быть в курсе обновлений.

governance as a code
highload++
программирование
архитектура по
тестирование
автоматизация

Блог компании Конференции Олега Бунина (Онтико)
Программирование
Тестирование веб-сервисов

Перевод «corporate governance code» на русский

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

Since the beginning of this year, 361 joint-stock companies started the implementation of the corporate governance code in accordance with the requirements of modern international management methods.

С начала текущего года в 361 акционерном обществе начато внедрение Кодекса корпоративного управления в соответствии с требованиями современных международных методов менеджмента.

We have adopted a corporate governance code that focuses on the best of the OECD standards, and that is a trendsetter in this area.

Мы приняли кодекс корпоративного управления, ориентированный на лучшие стандарты ОЭСР, а это законодатель мод в данной сфере.

The government said it would ask the Financial Reporting Council — the accountancy regulator that oversees the corporate governance code for all listed stock market companies — to consult on the three options.

Правительство заявляет, что будет просить Совет по финансовой отчетности — бухгалтерской регулятор, который контролирует кодекс корпоративного управления на фондовом рынке компаний — консультации по трем вариантам.

The next external evaluation will occur within the three-year period in accordance with the Corporate Governance Code.

Следующая внешняя оценка будет проводиться в течение трехлетнего периода в соответствии с Кодексом корпоративного управления.

In accordance with the UK Corporate Governance Code, the directors are subject to annual re-election by shareholders.

В соответствии с Кодексом корпоративного управления Великобритании директора ежегодно подлежат переизбранию акционерами.

In the absence of a strong legal framework, a group of major Russian companies has teamed up to draft their own corporate governance code.

В отсутствие жестких правовых ограничений группа крупных российских компаний объединила усилия по разработке собственного кодекса корпоративного управления.

Company’s corporate governance code aligned with best international practices
Кодекс корпоративного управления соответствует лучшим международным практикам

In South Africa, companies listed on the Johannesburg Stock Exchange must disclose compliance with a national corporate governance code that recommends integrated financial and non-financial reporting.

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

Its assets could consist of shares in some of the existing Ukrainian SOEs and be subject to a new corporate governance code and managed, like FP, by a reputable financial manager selected pursuant to a transparent request for proposal process.

Его активы могут состоять из акций некоторых существующих украинских государственных предприятий, подпадать под новый кодекс корпоративного управления и управляться, как и FP, авторитетным финансовым руководителем, выбранным на конкурсе.

«The next step is for the corporate governance code to recognise the important role that unions play in the long-term success of companies,» she added.

«Следующим шагом является кодекс корпоративного управления, чтобы признать важную роль, которую профсоюзы играют в долгосрочный успех компании», — добавила она.

The fund owns significant minority shares of valuable Romanian SOEs and has used its position to create greater transparency in these companies and to push the Romanian government to adopt a progressive corporate governance code.

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

As legislation develops changes of July 8, 2005 added approval of corporate governance code (as well changes and amendments) to issues which shall be approved by qualified majority.

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

Under the administration of Prime Minister Shinzo Abe, Japan’s Financial Services Agency introduced a new corporate governance code two years ago.

Под руководством премьер-министра Синдзо Абэ Японское агентство по финансовым услугам два года назад ввело новый кодекс корпоративного управления.

Further, in Australia, reporting of listed issuer’s diversity policy is only subject to «comply or explain», and in the UK, only certain large listed companies must include a description of their diversity policies in their corporate governance code.

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

State-controlled joint stock companies (except for the National Welfare Fund) shall approve corporate governance codes in accordance with the model corporate governance code

Контролируемые государством акционерные общества (за исключением Фонда национального благосостояния) утверждают кодексы корпоративного управления в соответствии с типовым кодексом корпоративного управления

Keywords: alternative dispute resolution, mediation, principles of mediation, conciliation, Ombudsman, state rights activists, chamber of Commerce, court of honor, court of arbitration, code of business conduct, corporate governance code.

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

Where the company has decided not to apply any provisions of a corporate governance code referred to under points (a)(i) or (ii), it shall explain its reasons for doing so

Если компания приняла решение не применять какие-либо положения кодекса корпоративного управления, указанные в пунктах (a)(i) или (ii), она должна пояснить причины такого поведения.

Rosneft’s corporate governance system helps to safeguard all shareholder rights in accordance with legal requirements, the recommendations of the corporate governance code of the Bank of Russia and the Company’s internal regulations.

Система корпоративного управления Jscomsk Refinery помогает охранять все права акционеров в соответствии с требованиями законодательства, рекомендациями кодекса корпоративного управления Банка России и внутренними правилами Компании.

1-1) approval of the corporate governance code, as well as the changes and amendments to it if the adoption of the Code is provided by the company’s charter

утверждение кодекса корпоративного управления, а также изменений и дополнений в него в случае, если принятие данного кодекса предусмотрено уставом общества

Возможно неприемлемое содержание

Примеры предназначены только для помощи в переводе искомых слов и выражений в различных контекстах. Мы не выбираем и не утверждаем примеры, и они могут содержать неприемлемые слова или идеи. Пожалуйста, сообщайте нам о примерах, которые, на Ваш взгляд, необходимо исправить или удалить. Грубые или разговорные переводы обычно отмечены красным или оранжевым цветом.

Зарегистрируйтесь, чтобы увидеть больше примеров. Это просто и бесплатно
Ничего не найдено для этого значения.
Предложить пример
Больше примеров Предложить пример

Предложения, которые содержат corporate governance code

Новое: Reverso для Windows

Переводите текст из любого приложения одним щелчком мыши .

Скачать бесплатно
Перевод голосом, функции оффлайн, синонимы, спряжение, обучающие игры

Результатов: 412 . Точных совпадений: 412 . Затраченное время: 134 мс

Помогаем миллионам людей и компаний общаться более эффективно на всех языках.

FinOps с помощью Governance-as-Code

Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В этой статье мы рассмотрим, почему развивающаяся практика облачного финансового управления (FinOps) так важна для сдерживания затрат. Затем мы обсудим проблемы, с которыми сталкиваются команды, когда они начинают применять подходы FinOps. Наконец, мы расскажем о возможностях, появляющихся при применении концепции «руководство-как-код» (governance-as-code) для обеспечения непрерывной оптимизации затрат в облаке, и о том, как этот подход позволяет командам применять теорию FinOps на практике, чтобы они могли контролировать затраты на облачные технологии.

Появление FinOps

Многие организации сегодня участвуют в «гонке облачных сервисов», в рамках которой команды стремятся реализовать преимущества в отношении гибкости, адаптивности и эффективности. Проблема состоит не только в увеличении рабочей нагрузки на «облака», но и в использовании большего числа вариаций различных моделей развертывания, большем количестве команд, использующих облачные сервисы, и в большем числе используемых поставщиков услуг.

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

Эта потребность в улучшении управления затратами привела к появлению новой дисциплины: управление облачными финансами, или FinOps. Если коротко, FinOps — это способ привести управление финансами и отчетность в соответствие с парадигмой переменных затрат, характерной для «облаков». FinOps объединяет технологии, процессы и команды, включая профессионалов в области технологий, финансов и бизнеса. Получив улучшенную способность понимать, отслеживать и управлять затратами на облако, команды могут начать максимизировать ценность, получаемую за счет своих расходов. Учитывая стратегический и срочный характер управления облачными затратами, неудивительно, что команды FinOps растут. Согласно исследованию, проведенному Фондом FinOps, команды FinOps увеличились на 47% по сравнению с прошлым годом, и эти профессионалы ожидают, что их команды вырастут на 75% в следующем году.

Проблемы при создании FinOps

Несмотря на то, что внедрение практики FinOps сулит много перспектив, на пути команд также стоит множество препятствий. По результатам опросов, проведённых FinOps Foundation, были выявлены пять основных сложностей:

Побуждение инженеров к действию (39%)
Работа с общими (разделяемыми) затратами (33 %)
Точность прогнозирования (26%)
Сокращение непроизводительных затратах (waste) или неиспользуемых ресурсов (25 %)
Полнота распределения затрат (23 %)

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

Эти проблемы усугубляются тем фактом, что в разных командах используются разные инструменты и процессы. Например, разные команды разработчиков могут использовать разные сервисы поставщиков наряду с различными инструментами развертывания. Это несоответствие приводит к неэффективности и недопониманию и снижает производительность команды.

Хотя облако предлагает ряд преимуществ по сравнению с устаревшей «железной» инфраструктурой, без надлежащего управления затраты на облако могут быстро выйти из-под контроля. Фактически, аналитики Gartner сообщают, что в ближайшие несколько лет 60 % организаций столкнутся с перерасходом средств на использование общедоступных облаков.

Переосмысление управления затратами

По всем причинам, изложенным выше, командам предлагается использовать новый подход к управлению облачными затратами, который соответствует принципам FinOps. Для многих это означает принятие концепции «руководство-как-код» (governance-as-code) для оптимизации затрат на облако. Это способ автоматического и динамического применения политик, в том числе для оптимизации затрат, в быстро меняющихся облачных средах.

При использовании подхода «руководство-как-код» политика определяется с использованием стандартного языка. Код, связанный с политикой затрат, создается, развертывается и поддерживается во многом таким же образом, как осуществляется управление кодом приложения или инфраструктуры. Разработчикам не нужно беспокоиться об отслеживании или управлении затратами. Политика затрат постоянно оценивается с учетом текущего состояния, использования и конфигурации облачной инфраструктуры. В случае возникновения каких-либо нарушений могут быть запущены автоматические уведомления и рабочие процессы. Ниже приведены ключевые требования к использованию подхода «руководство-как-код» для обеспечения непрерывной оптимизации затрат в облаке.

Политика затрат определяется с помощью интуитивно понятного языка

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

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

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

Политики затрат управляются и развертываются с помощью конвейера CI/CD

После того, как политики будут пересмотрены и доработаны, команды должны иметь возможность применять эти политики в рамках существующих рабочих процессов непрерывной интеграции/непрерывной доставки (CI/CD).

Благодаря подходу «руководство-как-код» команды могут создавать политики затрат в виде артефактов кода и развертывать их с помощью систем управления версиями с открытым исходным кодом, таких как Git. Благодаря такому подходу команды могут применять политики таким образом, чтобы это соответствовало их жизненным циклам разработки и доставки программного обеспечения.

Таким образом, средства контроля затрат могут быть развернуты с помощью Git в рамках конвейера CI/CD. Такой подход позволяет командам избегать сложных ручных процессов, связанных с такими задачами, как управление запросами на обслуживание, запросами на изменения и так далее. Это также помогает командам идти в ногу с ускоряющимися темпами современных динамичных облачных сред и сред разработки. Кроме того, этот подход означает, что «руководящий код» (governance code) можно отслеживать с помощью различных изменений состояния, откатывать при необходимости — точно так же, как код приложения.

Нарушения политики затрат выявляются и устраняются в режиме реального времени

Благодаря непрерывной оптимизации облачных затрат с помощью подхода «руководство-как-код» команды получают возможность не только осуществлять непрерывное обнаружение, но и принимать немедленные меры. Политики могут применяться с регулярными запланированными интервалами или запускаться в зависимости от определенных событий. Этот подход позволяет применять рабочие процессы и действия, которые могут потребоваться. Если происходят нарушения политики, уведомления соответствующим командам или членам команды могут отправляться автоматически, и могут запускаться расширенные рабочие процессы.

Политика затрат постоянно внедряется и совершенствуется

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

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

Оригинал статьи доступен по ссылке.

Также по теме:

Govern the governance? Или все-таки manage?
Профессорский взгляд на Governance
IT Governance для чайников
Culture as Code
Семинар itSMF России «Управление ИТ-активами — аспект контроля затрат и оптимизации ИТ-бюджета»