Tag Archives: 54

Keeping Time With Amazon Time Sync Service

Post Syndicated from Randall Hunt original https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/

Today we’re launching Amazon Time Sync Service, a time synchronization service delivered over Network Time Protocol (NTP) which uses a fleet of redundant satellite-connected and atomic clocks in each region to deliver a highly accurate reference clock. This service is provided at no additional charge and is immediately available in all public AWS regions to all instances running in a VPC.

You can access the service via the link local 169.254.169.123 IP address. This means you don’t need to configure external internet access and the service can be securely accessed from within your private subnets.

Setup

Chrony is a different implementation of NTP than what ntpd uses and it’s able to synchronize the system clock faster and with better accuracy than ntpd. I’d recommend using Chrony unless you have a legacy reason to use ntpd.

Installing and configuring chrony on Amazon Linux is as simple as:


sudo yum erase ntp*
sudo yum -y install chrony
sudo service chronyd start

Alternatively, just modify your existing NTP config by adding the line server 169.254.169.123 prefer iburst.

On Windows you can run the following commands in PowerShell or a command prompt:


net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"169.254.169.123"
w32tm /config /reliable:yes
net start w32time

Leap Seconds

Time is hard. Science, and society, measure time with respect to the International Celestial Reference Frame (ICRF), which is computed using long baseline interferometry of distant quasars, GPS satellite orbits, and laser ranging of the moon (cool!). Irregularities in Earth’s rate of rotation cause UTC to drift from time with respect to the ICRF. To address this clock drift the International Earth Rotation and Reference Systems (IERS) occasionally introduce an extra second into UTC to keep it within 0.9 seconds of real time.

Leap seconds are known to cause application errors and this can be a concern for many savvy developers and systems administrators. The 169.254.169.123 clock smooths out leap seconds some period of time (commonly called leap smearing) which makes it easy for your applications to deal with leap seconds.

This timely update should provide immediate benefits to anyone previously relying on an external time synchronization service.

Randall

PS – We are still working to make this feature available for M5 and C5 instances. Read Configuring the Amazon Time Service to learn more.

КЗЛД: Десет практически стъпки за прилагане на новия Регламент относно защитата на данните (GDPR)

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/28/gdpr/

На 25 май 2018 г. влиза в сила новият Общ регламент относно защитата на   данните –  Регламент (ЕС) 2016/679 на Европейския парламент и на Съвета от 27 април 2016 година относно защитата на физическите лица във връзка с обработването на лични данни и относно свободното движение на такива данни и за отмяна на Директива 95/46/EО 

Комисията за защита на личните данни е издала указания – десет практически стъпки за прилагане на новия Общ регламент.

 

 

Filed under: Digital, EU Law, Media Law Tagged: gdpr

Отворено законодателство [лекция]

Post Syndicated from Bozho original https://blog.bozho.net/blog/2996

Преди година написах, че макар гражданите да са длъжни да знаят законите, държавата не им помага по никакъв начин за това – законите се публикуват само като изменения в държавен вестник (чиято електронна форма е PDF), а за нормален човек това не е четимо и полезно но никакъв начин. Това ни прави почти последни в Европа по достъпност на законодателството. Причините за това са много, свързани и с авторски права, и с неспособността на държавата да върши качествено И тази работа, но в крайна сметка гражданите ползваме lex.bg и се надяваме версията там да е актуална.

Това обаче е недостатъчно и поради това реших да направя лекция за „Отворено законодателство“ на OpenFest, на която да разкажа както за текущия законодателен процес и проблемите, свързани с него, така и да предложа технически решения. В рамките на лекцията предложих създаване на проект OpenLex, чрез който законодателството да стане по-достъпно.

Видео от лекцията може да видите тук:

А слайдовете са тук:

Три седмици след OpenFest, все още не съм намерил време да инициирам координационна среща по проекта с хората изявили желание, което е сериозен пропуск от моя страна, но ще се опитам да го коригирам скоро.

А ако проектът бъде реализиран, ще имаме не просто по-удобно и достъпно законодателство (каквото lex.bg до известна степен дава), но и реализирани компоненти и взети технически решения, чрез които държавата (в лицето или на Народното събрание, или на Министерския съвет) да поддържа законодателството в електронен, машинно-четим вид. А самият законодателен процес да не минава през разпечатване, сканиране и разпращане на doc файлове с 10 цвята в допълнение на track changes, а да бъде структуриран и да позволява съвместна работа на много участници. Това би предполагало технически грамотни депутати, разбира се. Ама и до там ще стигнем все някой ден.

Надявам се и лекцията ми да е полезна за всеки, който в даден бъдещ момент ще иска да оптимизира законодателния процес и достъпа до законодателство.

Rightscorp: Revenue From Piracy Settlements Down 48% in 2017

Post Syndicated from Andy original https://torrentfreak.com/rightscorp-revenue-from-piracy-settlements-down-48-in-2017-171125/

For the past several years, anti-piracy outfit Rightscorp has been trying to turn piracy into profit. The company monitors BitTorrent networks, captures IP addresses, then attempts to force ISPs to forward cash settlement demands to its subscribers.

Unlike other companies operating in the same area, Rightscorp has adopted a “speeding fine” type model, where it asks for $20 to $30 to make a supposed lawsuit go away, instead of the many hundreds demanded by its rivals. To date, this has resulted in the company closing more than 230,000 cases of infringement.

But despite the high numbers, the company doesn’t seem to be able to make it pay. Rightscorp’s latest set of financial results covering the three months ended September 30, 2017, show how bad things have got on the settlement front.

During the period in question, Rightscorp generated copyright settlement revenues of $45,848, an average of just $15,282 per month. That represents a decrease of 67% when compared to the $139,834 generated during the same period in 2016.

When looking at settlement revenues year to date, Rightscorp generated $184,362 in 2017, a decrease of 48% when compared to $354,160 generated during the same nine-month period in 2016.

But as bleak as these figures are, things get much worse. Out of these top-line revenues, Rightscorp has to deal with a whole bunch of costs before it can put anything into its own pockets. For example, in exchange for the right to pursue pirates, Rightscorp agrees to pay around 50% of everything it generates from settlements back to copyright holders.

So, for the past three months when it collected $45,848 from BitTorrent users, it must pay out $22,924 to copyright holders. Last year, in the same period, it paid them $69,143. For the year to date (nine months ended September 30, 2017), the company paid $92,181 to copyright holders, that’s versus $174,878 for the same period last year.

Whichever way you slice it, Rightscorp settlement model appears to be failing. With revenues from settlements down by almost half thus far this year, one has to question where this is all going, especially with BitTorrent piracy volumes continuing to fall in favor of other less traceable methods such as streaming.

However, Rightscorp does have a trick up its sleeve that is helping to keep the company afloat. As previously reported, the company has amassed a lot of intelligence on pirate activity which clearly has some value to copyright holders.

That data is currently being utilized by both BMG and the RIAA, who are using it as evidence in copyright liability lawsuits filed against ISPs Cox and Grande Communications, where each stand accused of failing to disconnect repeat infringers.

This selling of ‘pirate’ data is listed by Rightscorp in its financial reports as “consulting services” and thus far at least, it’s proving to be a crucial source of income.

“During the three months ended September 30, 2017, we generated revenues of $76,666 from consulting services rendered under service arrangements with prominent trade organizations,” Rightscorp reports.

“Under the agreements, the Company is providing certain data and consultation regarding copyright infringements on such organizations’ respective properties. During the three months ended September 30, 2016, we had no consulting services revenue.”

Year to date, the numbers begin to add up. In the nine months ended September 30, 2017, Rightscorp generated revenues of $224,998 from this facet of their business, that’s versus zero revenue in 2016.

It’s clear that without this “consulting” revenue, Rightscorp would be in an even worse situation than it is today. In fact, it appears that these services, provided to the likes of the RIAA, are now preventing the company from falling into the abyss. All that being said, there’s no guarantee that won’t happen anyway.

To the nine months ended September 30, 2017, Rightscorp recorded a net loss of $1,448,899, which is even more than the $1,380,698 it lost during the same period last year. As a result, the company had just $3,147 left in cash at the end of September. That crisis was eased by issuing 2.5 million shares to an investor for a purchase price just $50,000. But to keep going, Rightscorp will need more money – much more.

“Management believes that the Company will need an additional $250,000 to $500,000 in 2017 to fund operations based on our current operating plans,” it reports, noting that there is “substantial doubt” whether Rightscorp can continue as a going concern.

But despite all the bad news, Rightscorp manages to survive and at least in the short-term, the piracy data it has amassed holds value, beyond basic cash settlement letters. The question is, for how long?

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN discounts, offers and coupons

Права върху снимка

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/18/photo_copyright/

Маймуната Наруто си прави селфи с фотоапарата на британския фотограф Дейвид Слейтър. На кого са правата върху снимката? На този, който натиска бутона? На Наруто? На Брадли Купър, който заснема с апарата на Дедженерис  група  кинозвезди в нощта на Оскарите?

На Наруто, на фотографа – или снимката е в публичния домейн?

За всяка от трите опции  има субект с интерес:  Дружеството за защита на животните,  Дейвид Слейтър и Уикипедия.

Слейтър постига извънсъдебно споразумение с дружеството, сега се очаква и дело с Уикипедия. Именно по този повод вчера е излязла интересна публикация с позоваване на практиката на Съда на ЕС: фотографията е повече от натискане на бутон  – снимката   може да има характера на художествено произведение по смисъла  на закона за авторското право, ако задачата оставя  достатъчно пространство за индивидуално творческо решение – вж делото C‑145/10 Painer:

88      Както следва от съображение 17 от Директива 93/98, дадено интелектуално творение е собствено авторско интелектуално творение, когато то отразява личността на автора.

89      Такъв е обаче случаят, ако авторът е могъл да изрази своите творчески способности при реализирането на произведението, като е направил свободен и творчески избор (вж. a contrario Решение от 4 октомври 2011 г. по дело Football Association Premier League и др., C‑403/08 и C‑429/08, точка 98).

90      Що се отнася до портретна снимка, следва да се посочи, че авторът може да направи своя свободен и творчески избор по няколко начини и в различни моменти при реализирането ѝ.

91      На подготвителния етап авторът може да избере фона на снимката, позата на сниманото лице или осветлението. При заснемането на портретната снимка той може да избере разполагането в кадър, ъгъла на снимане или още създадената атмосфера. Накрая, при проявяването на снимката авторът може да избере между различните съществуващи техники на проявяване тази, която желае да възприеме, или, ако е необходимо, да използва софтуер.

92      Чрез тези различни видове избор авторът на дадена портретна снимка може по този начин да остави своя „индивидуален отпечатък“ върху създаденото произведение.

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

94      С оглед на гореизложеното, следва да се приеме, че по силата на член 6 от Директива 93/98 портретна снимка може да бъде закриляна от авторско право, при условие — което националната юрисдикция следва да провери във всеки конкретен случай — че такава фотография е авторско интелектуално творение, което отразява личността на автора и е проява на неговия свободен и творчески избор при реализирането на тази фотография.

 

Filed under: Media Law Tagged: снимка, съд на ес

Одобрението за членството на България в ЕС се запазва

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/17/eu_poll/

Одобрението за членството на България в ЕС се запазва в рамките на 50 на сто, срещу 16% неодобрение и 34% неутрални оценки.

Най-силни еврооптимисти остават по-младите, с по-високо образование, активност и мобилност, които са се възползвали най-пълноценно  от предимствата на членството.

Национално представително проучване на Алфа Рисърч, проведено по поръчка на Представителството на ЕК в България, в периода 16 – 25 септември 2017 г.

 

Filed under: Uncategorized

Capturing Custom, High-Resolution Metrics from Containers Using AWS Step Functions and AWS Lambda

Post Syndicated from Nathan Taber original https://aws.amazon.com/blogs/compute/capturing-custom-high-resolution-metrics-from-containers-using-aws-step-functions-and-aws-lambda/

Contributed by Trevor Sullivan, AWS Solutions Architect

When you deploy containers with Amazon ECS, are you gathering all of the key metrics so that you can correctly monitor the overall health of your ECS cluster?

By default, ECS writes metrics to Amazon CloudWatch in 5-minute increments. For complex or large services, this may not be sufficient to make scaling decisions quickly. You may want to respond immediately to changes in workload or to identify application performance problems. Last July, CloudWatch announced support for high-resolution metrics, up to a per-second basis.

These high-resolution metrics can be used to give you a clearer picture of the load and performance for your applications, containers, clusters, and hosts. In this post, I discuss how you can use AWS Step Functions, along with AWS Lambda, to cost effectively record high-resolution metrics into CloudWatch. You implement this solution using a serverless architecture, which keeps your costs low and makes it easier to troubleshoot the solution.

To show how this works, you retrieve some useful metric data from an ECS cluster running in the same AWS account and region (Oregon, us-west-2) as the Step Functions state machine and Lambda function. However, you can use this architecture to retrieve any custom application metrics from any resource in any AWS account and region.

Why Step Functions?

Step Functions enables you to orchestrate multi-step tasks in the AWS Cloud that run for any period of time, up to a year. Effectively, you’re building a blueprint for an end-to-end process. After it’s built, you can execute the process as many times as you want.

For this architecture, you gather metrics from an ECS cluster, every five seconds, and then write the metric data to CloudWatch. After your ECS cluster metrics are stored in CloudWatch, you can create CloudWatch alarms to notify you. An alarm can also trigger an automated remediation activity such as scaling ECS services, when a metric exceeds a threshold defined by you.

When you build a Step Functions state machine, you define the different states inside it as JSON objects. The bulk of the work in Step Functions is handled by the common task state, which invokes Lambda functions or Step Functions activities. There is also a built-in library of other useful states that allow you to control the execution flow of your program.

One of the most useful state types in Step Functions is the parallel state. Each parallel state in your state machine can have one or more branches, each of which is executed in parallel. Another useful state type is the wait state, which waits for a period of time before moving to the next state.

In this walkthrough, you combine these three states (parallel, wait, and task) to create a state machine that triggers a Lambda function, which then gathers metrics from your ECS cluster.

Step Functions pricing

This state machine is executed every minute, resulting in 60 executions per hour, and 1,440 executions per day. Step Functions is billed per state transition, including the Start and End state transitions, and giving you approximately 37,440 state transitions per day. To reach this number, I’m using this estimated math:

26 state transitions per-execution x 60 minutes x 24 hours

Based on current pricing, at $0.000025 per state transition, the daily cost of this metric gathering state machine would be $0.936.

Step Functions offers an indefinite 4,000 free state transitions every month. This benefit is available to all customers, not just customers who are still under the 12-month AWS Free Tier. For more information and cost example scenarios, see Step Functions pricing.

Why Lambda?

The goal is to capture metrics from an ECS cluster, and write the metric data to CloudWatch. This is a straightforward, short-running process that makes Lambda the perfect place to run your code. Lambda is one of the key services that makes up “Serverless” application architectures. It enables you to consume compute capacity only when your code is actually executing.

The process of gathering metric data from ECS and writing it to CloudWatch takes a short period of time. In fact, my average Lambda function execution time, while developing this post, is only about 250 milliseconds on average. For every five-second interval that occurs, I’m only using 1/20th of the compute time that I’d otherwise be paying for.

Lambda pricing

For billing purposes, Lambda execution time is rounded up to the nearest 100-ms interval. In general, based on the metrics that I observed during development, a 250-ms runtime would be billed at 300 ms. Here, I calculate the cost of this Lambda function executing on a daily basis.

Assuming 31 days in each month, there would be 535,680 five-second intervals (31 days x 24 hours x 60 minutes x 12 five-second intervals = 535,680). The Lambda function is invoked every five-second interval, by the Step Functions state machine, and runs for a 300-ms period. At current Lambda pricing, for a 128-MB function, you would be paying approximately the following:

Total compute

Total executions = 535,680
Total compute = total executions x (3 x $0.000000208 per 100 ms) = $0.334 per day

Total requests

Total requests = (535,680 / 1000000) * $0.20 per million requests = $0.11 per day

Total Lambda Cost

$0.11 requests + $0.334 compute time = $0.444 per day

Similar to Step Functions, Lambda offers an indefinite free tier. For more information, see Lambda Pricing.

Walkthrough

In the following sections, I step through the process of configuring the solution just discussed. If you follow along, at a high level, you will:

  • Configure an IAM role and policy
  • Create a Step Functions state machine to control metric gathering execution
  • Create a metric-gathering Lambda function
  • Configure a CloudWatch Events rule to trigger the state machine
  • Validate the solution

Prerequisites

You should already have an AWS account with a running ECS cluster. If you don’t have one running, you can easily deploy a Docker container on an ECS cluster using the AWS Management Console. In the example produced for this post, I use an ECS cluster running Windows Server (currently in beta), but either a Linux or Windows Server cluster works.

Create an IAM role and policy

First, create an IAM role and policy that enables Step Functions, Lambda, and CloudWatch to communicate with each other.

  • The CloudWatch Events rule needs permissions to trigger the Step Functions state machine.
  • The Step Functions state machine needs permissions to trigger the Lambda function.
  • The Lambda function needs permissions to query ECS and then write to CloudWatch Logs and metrics.

When you create the state machine, Lambda function, and CloudWatch Events rule, you assign this role to each of those resources. Upon execution, each of these resources assumes the specified role and executes using the role’s permissions.

  1. Open the IAM console.
  2. Choose Roles, create New Role.
  3. For Role Name, enter WriteMetricFromStepFunction.
  4. Choose Save.

Create the IAM role trust relationship
The trust relationship (also known as the assume role policy document) for your IAM role looks like the following JSON document. As you can see from the document, your IAM role needs to trust the Lambda, CloudWatch Events, and Step Functions services. By configuring your role to trust these services, they can assume this role and inherit the role permissions.

  1. Open the IAM console.
  2. Choose Roles and select the IAM role previously created.
  3. Choose Trust RelationshipsEdit Trust Relationships.
  4. Enter the following trust policy text and choose Save.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "states.us-west-2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create an IAM policy

After you’ve finished configuring your role’s trust relationship, grant the role access to the other AWS resources that make up the solution.

The IAM policy is what gives your IAM role permissions to access various resources. You must whitelist explicitly the specific resources to which your role has access, because the default IAM behavior is to deny access to any AWS resources.

I’ve tried to keep this policy document as generic as possible, without allowing permissions to be too open. If the name of your ECS cluster is different than the one in the example policy below, make sure that you update the policy document before attaching it to your IAM role. You can attach this policy as an inline policy, instead of creating the policy separately first. However, either approach is valid.

  1. Open the IAM console.
  2. Select the IAM role, and choose Permissions.
  3. Choose Add in-line policy.
  4. Choose Custom Policy and then enter the following policy. The inline policy name does not matter.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [ "logs:*" ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [ "cloudwatch:PutMetricData" ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [ "states:StartExecution" ],
            "Resource": [
                "arn:aws:states:*:*:stateMachine:WriteMetricFromStepFunction"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [ "lambda:InvokeFunction" ],
            "Resource": "arn:aws:lambda:*:*:function:WriteMetricFromStepFunction"
        },
        {
            "Effect": "Allow",
            "Action": [ "ecs:Describe*" ],
            "Resource": "arn:aws:ecs:*:*:cluster/ECSEsgaroth"
        }
    ]
}

Create a Step Functions state machine

In this section, you create a Step Functions state machine that invokes the metric-gathering Lambda function every five (5) seconds, for a one-minute period. If you divide a minute (60) seconds into equal parts of five-second intervals, you get 12. Based on this math, you create 12 branches, in a single parallel state, in the state machine. Each branch triggers the metric-gathering Lambda function at a different five-second marker, throughout the one-minute period. After all of the parallel branches finish executing, the Step Functions execution completes and another begins.

Follow these steps to create your Step Functions state machine:

  1. Open the Step Functions console.
  2. Choose DashboardCreate State Machine.
  3. For State Machine Name, enter WriteMetricFromStepFunction.
  4. Enter the state machine code below into the editor. Make sure that you insert your own AWS account ID for every instance of “676655494xxx”
  5. Choose Create State Machine.
  6. Select the WriteMetricFromStepFunction IAM role that you previously created.
{
    "Comment": "Writes ECS metrics to CloudWatch every five seconds, for a one-minute period.",
    "StartAt": "ParallelMetric",
    "States": {
      "ParallelMetric": {
        "Type": "Parallel",
        "Branches": [
          {
            "StartAt": "WriteMetricLambda",
            "States": {
             	"WriteMetricLambda": {
                  "Type": "Task",
				  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
    	  {
            "StartAt": "WaitFive",
            "States": {
            	"WaitFive": {
            		"Type": "Wait",
            		"Seconds": 5,
            		"Next": "WriteMetricLambdaFive"
          		},
             	"WriteMetricLambdaFive": {
                  "Type": "Task",
				  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
    	  {
            "StartAt": "WaitTen",
            "States": {
            	"WaitTen": {
            		"Type": "Wait",
            		"Seconds": 10,
            		"Next": "WriteMetricLambda10"
          		},
             	"WriteMetricLambda10": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
    	  {
            "StartAt": "WaitFifteen",
            "States": {
            	"WaitFifteen": {
            		"Type": "Wait",
            		"Seconds": 15,
            		"Next": "WriteMetricLambda15"
          		},
             	"WriteMetricLambda15": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait20",
            "States": {
            	"Wait20": {
            		"Type": "Wait",
            		"Seconds": 20,
            		"Next": "WriteMetricLambda20"
          		},
             	"WriteMetricLambda20": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait25",
            "States": {
            	"Wait25": {
            		"Type": "Wait",
            		"Seconds": 25,
            		"Next": "WriteMetricLambda25"
          		},
             	"WriteMetricLambda25": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait30",
            "States": {
            	"Wait30": {
            		"Type": "Wait",
            		"Seconds": 30,
            		"Next": "WriteMetricLambda30"
          		},
             	"WriteMetricLambda30": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait35",
            "States": {
            	"Wait35": {
            		"Type": "Wait",
            		"Seconds": 35,
            		"Next": "WriteMetricLambda35"
          		},
             	"WriteMetricLambda35": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait40",
            "States": {
            	"Wait40": {
            		"Type": "Wait",
            		"Seconds": 40,
            		"Next": "WriteMetricLambda40"
          		},
             	"WriteMetricLambda40": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait45",
            "States": {
            	"Wait45": {
            		"Type": "Wait",
            		"Seconds": 45,
            		"Next": "WriteMetricLambda45"
          		},
             	"WriteMetricLambda45": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait50",
            "States": {
            	"Wait50": {
            		"Type": "Wait",
            		"Seconds": 50,
            		"Next": "WriteMetricLambda50"
          		},
             	"WriteMetricLambda50": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          },
          {
            "StartAt": "Wait55",
            "States": {
            	"Wait55": {
            		"Type": "Wait",
            		"Seconds": 55,
            		"Next": "WriteMetricLambda55"
          		},
             	"WriteMetricLambda55": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:us-west-2:676655494xxx:function:WriteMetricFromStepFunction",
                  "End": true
                } 
            }
          }
        ],
        "End": true
      }
  }
}

Now you’ve got a shiny new Step Functions state machine! However, you might ask yourself, “After the state machine has been created, how does it get executed?” Before I answer that question, create the Lambda function that writes the custom metric, and then you get the end-to-end process moving.

Create a Lambda function

The meaty part of the solution is a Lambda function, written to consume the Python 3.6 runtime, that retrieves metric values from ECS, and then writes them to CloudWatch. This Lambda function is what the Step Functions state machine is triggering every five seconds, via the Task states. Key points to remember:

The Lambda function needs permission to:

  • Write CloudWatch metrics (PutMetricData API).
  • Retrieve metrics from ECS clusters (DescribeCluster API).
  • Write StdOut to CloudWatch Logs.

Boto3, the AWS SDK for Python, is included in the Lambda execution environment for Python 2.x and 3.x.

Because Lambda includes the AWS SDK, you don’t have to worry about packaging it up and uploading it to Lambda. You can focus on writing code and automatically take a dependency on boto3.

As for permissions, you’ve already created the IAM role and attached a policy to it that enables your Lambda function to access the necessary API actions. When you create your Lambda function, make sure that you select the correct IAM role, to ensure it is invoked with the correct permissions.

The following Lambda function code is generic. So how does the Lambda function know which ECS cluster to gather metrics for? Your Step Functions state machine automatically passes in its state to the Lambda function. When you create your CloudWatch Events rule, you specify a simple JSON object that passes the desired ECS cluster name into your Step Functions state machine, which then passes it to the Lambda function.

Use the following property values as you create your Lambda function:

Function Name: WriteMetricFromStepFunction
Description: This Lambda function retrieves metric values from an ECS cluster and writes them to Amazon CloudWatch.
Runtime: Python3.6
Memory: 128 MB
IAM Role: WriteMetricFromStepFunction

import boto3

def handler(event, context):
    cw = boto3.client('cloudwatch')
    ecs = boto3.client('ecs')
    print('Got boto3 client objects')
    
    Dimension = {
        'Name': 'ClusterName',
        'Value': event['ECSClusterName']
    }

    cluster = get_ecs_cluster(ecs, Dimension['Value'])
    
    cw_args = {
       'Namespace': 'ECS',
       'MetricData': [
           {
               'MetricName': 'RunningTask',
               'Dimensions': [ Dimension ],
               'Value': cluster['runningTasksCount'],
               'Unit': 'Count',
               'StorageResolution': 1
           },
           {
               'MetricName': 'PendingTask',
               'Dimensions': [ Dimension ],
               'Value': cluster['pendingTasksCount'],
               'Unit': 'Count',
               'StorageResolution': 1
           },
           {
               'MetricName': 'ActiveServices',
               'Dimensions': [ Dimension ],
               'Value': cluster['activeServicesCount'],
               'Unit': 'Count',
               'StorageResolution': 1
           },
           {
               'MetricName': 'RegisteredContainerInstances',
               'Dimensions': [ Dimension ],
               'Value': cluster['registeredContainerInstancesCount'],
               'Unit': 'Count',
               'StorageResolution': 1
           }
        ]
    }
    cw.put_metric_data(**cw_args)
    print('Finished writing metric data')
    
def get_ecs_cluster(client, cluster_name):
    cluster = client.describe_clusters(clusters = [ cluster_name ])
    print('Retrieved cluster details from ECS')
    return cluster['clusters'][0]

Create the CloudWatch Events rule

Now you’ve created an IAM role and policy, Step Functions state machine, and Lambda function. How do these components actually start communicating with each other? The final step in this process is to set up a CloudWatch Events rule that triggers your metric-gathering Step Functions state machine every minute. You have two choices for your CloudWatch Events rule expression: rate or cron. In this example, use the cron expression.

A couple key learning points from creating the CloudWatch Events rule:

  • You can specify one or more targets, of different types (for example, Lambda function, Step Functions state machine, SNS topic, and so on).
  • You’re required to specify an IAM role with permissions to trigger your target.
    NOTE: This applies only to certain types of targets, including Step Functions state machines.
  • Each target that supports IAM roles can be triggered using a different IAM role, in the same CloudWatch Events rule.
  • Optional: You can provide custom JSON that is passed to your target Step Functions state machine as input.

Follow these steps to create the CloudWatch Events rule:

  1. Open the CloudWatch console.
  2. Choose Events, RulesCreate Rule.
  3. Select Schedule, Cron Expression, and then enter the following rule:
    0/1 * * * ? *
  4. Choose Add Target, Step Functions State MachineWriteMetricFromStepFunction.
  5. For Configure Input, select Constant (JSON Text).
  6. Enter the following JSON input, which is passed to Step Functions, while changing the cluster name accordingly:
    { "ECSClusterName": "ECSEsgaroth" }
  7. Choose Use Existing Role, WriteMetricFromStepFunction (the IAM role that you previously created).

After you’ve completed with these steps, your screen should look similar to this:

Validate the solution

Now that you have finished implementing the solution to gather high-resolution metrics from ECS, validate that it’s working properly.

  1. Open the CloudWatch console.
  2. Choose Metrics.
  3. Choose custom and select the ECS namespace.
  4. Choose the ClusterName metric dimension.

You should see your metrics listed below.

Troubleshoot configuration issues

If you aren’t receiving the expected ECS cluster metrics in CloudWatch, check for the following common configuration issues. Review the earlier procedures to make sure that the resources were properly configured.

  • The IAM role’s trust relationship is incorrectly configured.
    Make sure that the IAM role trusts Lambda, CloudWatch Events, and Step Functions in the correct region.
  • The IAM role does not have the correct policies attached to it.
    Make sure that you have copied the IAM policy correctly as an inline policy on the IAM role.
  • The CloudWatch Events rule is not triggering new Step Functions executions.
    Make sure that the target configuration on the rule has the correct Step Functions state machine and IAM role selected.
  • The Step Functions state machine is being executed, but failing part way through.
    Examine the detailed error message on the failed state within the failed Step Functions execution. It’s possible that the
  • IAM role does not have permissions to trigger the target Lambda function, that the target Lambda function may not exist, or that the Lambda function failed to complete successfully due to invalid permissions.
    Although the above list covers several different potential configuration issues, it is not comprehensive. Make sure that you understand how each service is connected to each other, how permissions are granted through IAM policies, and how IAM trust relationships work.

Conclusion

In this post, you implemented a Serverless solution to gather and record high-resolution application metrics from containers running on Amazon ECS into CloudWatch. The solution consists of a Step Functions state machine, Lambda function, CloudWatch Events rule, and an IAM role and policy. The data that you gather from this solution helps you rapidly identify issues with an ECS cluster.

To gather high-resolution metrics from any service, modify your Lambda function to gather the correct metrics from your target. If you prefer not to use Python, you can implement a Lambda function using one of the other supported runtimes, including Node.js, Java, or .NET Core. However, this post should give you the fundamental basics about capturing high-resolution metrics in CloudWatch.

If you found this post useful, or have questions, please comment below.

ЕСПЧ: свобода на изразяване и добро име

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/15/echr_reputation/

Стана известно решението на Съда за правата на човека по делото Einarsson v. Iceland. Съдът трябва да балансира правото на свободно изразяване на медиите и правото на добро име на г-н Ейнарсон и да се произнесе дали намесата е в нарушение на чл.8 ЕКПЧ.

Жалбоподателят  е радиоводещ, телевизионен водещ, известна публична фигура. Обвинен е в изнасилване, впоследствие всички обвинения срещу него са отхвърлени, тъй като доказателствата са недостатъчни. 

По този повод в Инстаграм се появява снимка на г-н Ейнарсон с квалификации (“Fuck you rapist bastard”).   Всеки потребител на платформата  има достъп до снимката. От Инстаграм снимката тръгва и към медиите. В съдебния  процес Исландският съд застава на страната на медиите, като намира, че става дума за обществени дебати, за лично менние – коментар и публичната фигура  не е оклеветена. Лицето се обръща към ЕСПЧ за нарушение на чл.8, право на личен живот.

ЕСПЧ анализира баланса между свободата на изразяване и защитата на доброто име. За разлика от Исландския съд, ЕСПЧ приема, че изнасилвач не е оценка, а твърдение  за факт, и че Исландският съд не е успял да постигне справедлив баланс на правата.

Член 8 от Конвенцията трябва да се тълкува в смисъл, че лицата, дори спорните публични лица, които са предизвикали разгорещени дебати  с поведението си  и публичните си  коментари, не трябва да търпят публично обвинение в насилствени престъпни действия […] Ето защо Съдът намира, че изявлението е от сериозно естество и може да навреди на доброто име на жалбоподателя   [52]

В частност, коментира се и факта, че става дума за онлайн съдържание:

Съдът счита за важно да припомни своята предишна съдебна практика –  предвид неговата достъпност и способността му да съхранява и да позволява обмен на огромно количество информация, интернет играе важна роля за повишаване на достъпа на обществеността до новини и улесняване на разпространението на информацията като цяло. Същевременно опасността от вреди […], особено по отношение на правото на зачитане на личния живот, със сигурност е по-висока отколкото при  пресата (вж.  Delfi AS срещу Естония). [46]

Нарушение на чл.8 ЕКПЧ.

Има  две особени мнения, според които  – напротив – не става дума за твърдение за факт, а за по-обща оценка предвид  възгледите на жалбоподателя в миналото като цяло. Освен това в особените мнения се напомня, че преценката по  начало следва да се предостави на националните съдилища.

Filed under: Digital, Media Law Tagged: еспч

Съд на ЕС: финансиране на обществена телевизия, приходите от реклама, казусът TV2 Danmark

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/11/tv2-danmark/

I

Публикувано е решение по делото C‑649/15 P TV2/Danmark A/S  срещу Европейска комисия.

С жалбата си TV2/Danmark   иска частична отмяна на решението на Общия съд, с което той отменя Решение 2011/839/ЕС на Комисията относно мерките, приведени в действие от Дания (C 2/03) за TV2/Danmark в частта, в която Комисията е приела, че приходите от реклама  са държавни помощи  и  отхвърля жалбата му в останалата ѝ част.

Държавни помощи — Член 107, параграф 1 ДФЕС — Обществена услуга по разпространение на радио- и телевизионни програми — Мерки, взети от датските органи за датския радио- и телевизионен оператор TV2/Danmark — Понятие за помощ, предоставена от държава членка или чрез ресурси на държава членка — Решение Altmark

TV2/Danmark е втората обществена телевизия в Дания. Дейността на обществената телевизия  се финансира от  такса, плащана от всички телевизионни зрители в Дания,  и от рекламна дейност.

В резултат на жалба, подадена  от SBS Broadcasting, ЕК анализира финансирането и приема, че това са държавни помощи, съвместими с вътрешния пазар  – с изключение на една сума, която представлява свръхкомпенсация.

Срещу решението на ЕК постъпват четири жалби. Общият съд отменя посоченото решение. Комисията преразглежда въпросните мерки. Тя запазва позицията си относно квалификацията на разглежданите мерки като „държавни помощи“ по смисъла на член 107, параграф 1 ДФЕС и приема, че приходите от реклама  представляват ресурси на държавата.

И второто решение на ЕК се обжалва. TV2/Danmark иска от Общия съд да отмени спорното решение в частта, в която Комисията е приела, че:

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

–        приходите от  такси, прехвърлени на регионалните станции на TV2/Danmark, представляват държавни помощи за TV2/Danmark,

–        приходите от реклама представляват държавни помощи за TV2/Danmark.

Общият съд отменя спорното решение в частта, в която Комисията е приела, че приходите от реклама представляват държавни помощи, и отхвърля жалбата в останалата ѝ част.

TV2/Danmark обжалва.

Жалбата  е отхвърлена в нейната цялост,  пълният текст на решението

II

В отделно решение Съдът се произнася и по дело C‑656/15 P   , в което Комисията иска от Съда  да отмени обжалваното съдебно решение в частта му, в която е отменено   решението на Комисията, че приходите от реклама, платени на TV2/Danmark чрез фонд TV2, представляват държавни помощи

Според ЕК:

Общият съд е тълкувал неправилно понятието „ресурси на държава членка“ по смисъла на член 107, параграф 1 ДФЕС.  Комисията поддържа, че тъй като TV2 Reklame е публично дружество, чийто единствен акционер е датската държава, това дружество е изцяло под контрола и на разположение на последната, така че средствата му е трябвало да се считат за ресурси на държава членка по смисъла на тази разпоредба. По-конкретно Комисията твърди, че произходът на съответните ресурси не е релевантен за такава квалификация и че първоначално частният характер на тези ресурси не отнема характера им на ресурси на държавата членка.

Според решението:

40      Съгласно постоянната практика на Съда, за да бъде квалифицирана дадена мярка като „помощ“ по смисъла на член 107, параграф 1 ДФЕС, трябва да са изпълнени всички посочени в тази разпоредба условия.

41      Посочената разпоредба предвижда четири условия. Първо, трябва да става въпрос за намеса на държавата или чрез ресурси на държавата. Второ, тази намеса трябва да може да засегне търговията между държавите членки. Трето, тя трябва да предоставя предимство на ползващия се от нея. Четвърто, тя трябва да нарушава или да създава опасност от нарушаване на конкуренцията (вж. решение  Altmark Trans и др.)

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

46      Освен това следва да се припомни, че съгласно постоянната практика на Съда член 107, параграф 1 ДФЕС обхваща всички имуществени средства, които публичните органи могат ефективно да използват, за да подкрепят предприятия, като е без значение дали тези средства спадат постоянно или не към патримониума на държавата. Ето защо, макар съответстващите на разглежданата мярка суми да не се притежават постоянно от държавата, обстоятелството, че те остават непрекъснато под публичен контрол и следователно на разположение на компетентните национални власти, е достатъчно, за да бъдат квалифицирани като „държавни ресурси“

47      Следователно, при положение че ресурсите на публичните предприятия попадат под контрола на държавата, така че са на нейно разположение, тези ресурси се обхващат от понятието „ресурси на държава членка“ по смисъла на член 107, параграф 1 ДФЕС. Всъщност посредством упражняването на своето доминиращо влияние върху тези предприятия държавата е напълно в състояние да насочи използването на техните средства, за да финансира евентуално специфични предимства в полза на други предприятия

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

53      При това положение съгласно припомнената в точки 43—48 от настоящото решение практика на Съда, разглежданите приходи представляват „ресурси на държава членка“ по смисъла на член 107, параграф 1 ДФЕС.

54      Следователно, като е приел, че приходите от продажбата от TV2 Reklame на рекламните блокове на TV2/Danmark и са преведени на последното посредством фонд TV2, не представляват ресурси на държава членка, поради което Комисията неправилно ги е квалифицирала като „държавна помощ“, Общият съд е допуснал грешка при прилагане на правото.

63      Впрочем, както вече бе отбелязано, настоящото дело се отнася до публични предприятия, в случая TV2 Reklame и фонд TV2, създадени, притежавани и упълномощени от датската държава, за да управляват приходите от продажбата на рекламните блокове на друго публично предприятие, а именно TV2/Danmark, така че тези приходи се намират под контрола и на разположение на датската държава.

По изложените съображения Съдът (първи състав) отменя решението на Общия съд TV2/Danmark/Комисия (T‑674/11, EU:T:2015:684), в частта му, в която е отменено Решение 2011/839/ЕС на Комисията относно мерките, приведени в действие от Дания (C 2/03) за TV2/Danmark, в частта, в която Европейската комисия е приела, че приходите от реклама, платени на TV2/Danmark чрез фонд TV2, представляват държавни помощи.

III

По дело C‑657/15 P  с предмет жалба на Viasat Broadcasting UK Ltd, установено в Уест Драйтън (Обединеното кралство) Съдът приема следното –

27      Според Viasat прехвърлянето на съответните средства чрез фонд TV2 не променя факта, че те са ресурси на държава членка, тъй като фонд TV2 също е публично предприятие, контролирано от датската държава.

28      Предвид тези обстоятелства Viasat счита, че настоящото дело се различава съществено от делата, по които са постановени решения от 13 март 2001 г., PreussenElektra (C‑379/98, EU:C:2001:160), и от 5 март 2009 г., UTECA (C‑222/07, EU:C:2009:124), отнасящи се до случаи, при които съответните ресурси в нито един момент не са напускали частния сектор.

Съдът уважава първото основание, изтъкнато от Viasat,  в подкрепа на жалбата му.

*

За заключенията на ГА

На вниманието на всички, които имат намерение да се произнасят по реформата на финансирането на обществените медии.

Filed under: EU Law, Media Law Tagged: съд на ес

За сексуалните посегателства и ценностите

Post Syndicated from Bozho original https://blog.bozho.net/blog/2979

Тези дни се появиха немалко статии и мнения, които омаловажаваха сексуалните посегателства срещу жени. Една от по-коментираните беше тази, в която тезата е грубо казано „аз два пъти имах шанса да съм в положение да откажа и да не стана жертва, значи всички сте мрънкала“. Темата тръгна от разкритията за Харви Уайстийн (или както там се чете), който се е възползвал от положението си на продуцент в отношенията си с млади актриси (ако мога да се изразя деликатно).

Разбира се, немалка част от мъжката част от населението е склонна да подмине всички случаи на сексуални посегателства, разказани в станалия „вайръл“ хештаг #MeТoo. Явно част и от женската, които (за щастие) не са ставали жертва на такива действия. А какви са те – ами всякакви, нежелани от жертвата действия със сексуален елемент.

Ще се опитам да дам кратки отговори на някои от стандартните подмятания и риторични въпроси, в които темата се неглижира, игнорира или дори повдигащите я биват обвинявани, че „то ако това е посегателство, така къде ще му излезе краят“.

Коментар: Какво толкова е едно опипване / стискане / …, нали не е изнасилване?
Отговор: Номинално не е изнасилване, да. Но е възползване от позицията на по-силния за задоволяване на сексуални желания. Именно позицията на невъзможност за съпротива (срещу „силния пол“) е това, което прави тези действия толкова проблемни. „Какво толкова е…“ не знам, но нека оставим жертвите да определят какво толкова е, не ние, които не сме били подложени на нещо такова. Имам едно може би нелепо сравнение, но ще го направя. Хора, чийто апартамент е бил обран, се чувстват ужасно. Не защото са им взели нещо (понякога почти нищо ценно не е взето), а защото някой е нарушил неприкосновеността на дома им. Разбил го е, омърсил го е, разпилял го, и вече обраният не се чувства комфортно в собствения си дом. Е, умножете това чувство по сто, защото става дума не за дом, а за тялото на жертвата.

К: Защо чак сега се сещат да кажат?
О: Защото дори сега, толкова години напред в социалното развитие, все още са посрещани с недоверие и обвинения (например, че „са си го търсили“). Освен това такова преживяване е травматично; нещо, което предпочиташ да забравиш; нещо, за което говоренето е трудно. Как отиваш и разказваш травматично преживяване, за което имаш опасения, че никой няма да ти повярва и даже може да има негативни ефекти върху теб?

К: Къде е границата? Не може ли да се натискат хора в дискотека?
О: Може, докато е доброволно. Да, под влияние на алкохола вероятно е по-трудно човек да разбере намеци на несъгласие, но „като се напия ставам свиня“ не е никакво оправдание. Някой като се напие може да взема пушката и да почва да стреля. Границата в някои случаи наистина е трудно да се установи, но тези случаи според мен са сравнително малко.

К: Какво сега, да подписваме декларации за всеки флирт ли?
О: Залитането в крайности е грешно. Граничните случаи, в които е трудно да се определи съгласие, са малко, и няма нужда процесът да бъде бюрократизиран

К: Жените трябва да са по-силни психически, ако искат да имат равни права!
О: Психическата стабилност, т.е. възможността да се справиш с едно такова посегателство без то да ти се отрази и без да те травмира е спектър, а не само две точки „мъж“ и „жена“. Някои са по-чувствителни, други – не. Но това колко си чувствителен по никакъв начин не трябва да влияе върху това какви права имаш. Ако не се съгласим по този въпрос, имаме по-сериозен проблем.

К: Преувеличават, изобщо няма толкова много случаи…
О: Дали е 50%, „всяка трета жена“ или „всяка пета“, разликата не е толкова съществена. На първо място, статистиката няма как да е напълно достоверна, защото много жени не си казват (защо – виж няколко отговора по-нагоре). Но дори и 5 процента да са – това пак е прекалено много. И трябва да посочим проблема, да четем за проблема, да знаем за него. За да не прекрачваме границата, и да не позволяваме прекрачването на границата да бъде „нормално“. А всъщност, всеки познава поне по една жена, която е била жертва на сексуално посегателство (дори да не се е стигнало до насилие).

К: Някакви хора изнудват и разрушават кариерата на звезди със спорни истории от миналото
О: Когато излезеш и разкажеш история, не е изнудване. Изнудване е ако заплашиш да разкажеш историята, ако изнудваният не направи нещо в твоя полза. В тези случаи изнудването често е доказауемо (става с писма/съобщения, които могат да бъдат приложени като доказателства в съд). Вероятно има случаи, в които изнудвания отказва да даде исканото, но не му се занимава със съдебен процес, а изнудващия спира да блъфира и разказва историята. Но това са прекалено малка част от случаите. Всъщност, популярните личности, замесени в такива скандали са много малка част от случаите. Просто чуваме за тях, защото са известни.

К: С тия истории целят само да придобият популярност
О: Ако ми кажете някой, който „е станал известен като жертвата на Х“, може и да започнем да спорим по тая хипотеза. Но едва ли има такива случаи. Не на последно място, кой точно иска да стане известен с това, че някой го е използвал за сексуално удовлетворение?

К: Те в Африка и някои мюсюлмански държавни са по-зле…
О: Е, и? В Саудитска арабия убиват с камъни, ама това не значи, че е окей ние да убиваме с Итонг (че сме по-развити). Да, в развитите общества жените имат значително повече права и са в много по-добра позиция отколкото в (част от) ислямския свят и в държави от третия свят. Но това не значи, че няма проблеми.

К: Не се ли превръщат тези скандали в лов на вещици?
О: Това винаги е риск. Махалото да отиде в другата посока; покрай сухото да изгори и суровото. Затова не трябва да оставяме нагнетяването на такова напрежение, което да избухне по определен повод. Може би Дъстин Хофман просто има вулгарен език, може би някой друг е имал зле изразени романтични намерения. Но може и да е унижаване от позиция на силния. Може да е сексуално посегателство. Да, социалните мрежи имат способността да заклеймяват прибързано, да демонизират. Но това е друг проблем (че трябва да се научим да ползваме технологиите не като средство за избиване на комплексите си, а за по-удобна комуникация).

К: Това ли е най-големият проблем?
О: Няма най-голям проблем. Има множество проблеми, често свързани помежду си, които с времето трябва да решаваме, движени от споделени ценности. Като ги решим, ще живеем по-добре. Като решим един конкретен, ще помогнем за решаването на няколко други. И така нататък.

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

И самият факт, че изобщо водим спорове за това дали „не се правят на ощипани“, показва, че проблемът продължава да го има. А той е, че изглежда все още нямаме базовата ценност, че чуждото тяло е неприкосновено.

EC2 Convertible Reserved Instance Update – New 1-Year CRI, Merges & Splits

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/ec2-convertible-reserved-instance-update-new-1-year-cri-merges-splits/

We launched Convertible Reserved Instances for EC2 just about a year ago. The Convertible RIs give you a significant discount (typically 54% when compared to On-Demand) and allow you to change the instance family and other parameters associated with the RI if your needs change.

Today we are introducing Convertible RIs with a 1-year term, complementing the existing 3-year term. We are also making the Convertible Reserved Instance model more flexible by allowing you to exchange portions of your RIs and to perform bulk exchanges.

New 1-Year Convertible RIs
Convertible Reserved Instances with a 1-year term are now available. This will give you more options and more flexibility; you can now purchase a mix of 1-year and 3-year Convertible Reserved Instances (CRIs) in accord with your needs. Startups with financial constraints will find this option attractive, as will other ventures that may not be in a position to make a commitment that runs for longer than one year.

Merging and Splitting Convertible RIs
Let’s say that you start running your web and application servers on M4 instances and uses Convertible RIs to save money. Later, after a tuning exercise you move your application servers to C4 instances. With today’s launch you can exchange a portion of your M4 Convertible RIs for C4 Convertible RIs. You can also merge two or more CRIs (perhaps for smaller instances) and obtain one for a larger instance.

The exchange model for Convertible Reserved Instances is based on splitting, exchanging, and merging. Let’s say I own a 3-year Partial Upfront CRI for four t2.micro instances:

My application has changed and now I want to use a pair of t2.micro instances and a single r4.xlarge. The first step is to split this CRI into the part that I want to keep and the part that I want to exchange. I select it and click on Modify Reserved Instances. Then I create my desired configuration and click on Continue:

I review the request and click on Submit Modifications:

The state of the CRI changes to indicate that it is being modified. After a moment or two it will be marked as retired, replaced by a pair that are active:

Now I can exchange one of the 2-instance CRIs. I select it, click on Exchange Reserved Instance, and enter the desired configuration for my new CRI:

I click on Find Offering to see my options, and choose the desired one, an r4.xlarge Partial Upfront. As you can see, the console “does the math” takes the remaining upfront value ($139.995 in this case) of the unneeded CRIs into account when computing the upfront payment:

When I am ready to move forward I click on Exchange. This initiates the exchange process and lets me know that it may take a few minutes to complete.

I can also merge two or more Convertible Reserved Instances together and then use them as the starting point for an exchange. To do this I simply select the existing CRIs, click on Action, and choose Exchange Reserved Instances. I can see the total remaining upfront value of the selected CRIs and proceed accordingly:

You can merge CRIs that have different start dates and/or term lengths. The merged CRI will have the expiry date of the RI that is furthest from the date of exchange. Merging CRIs with different term lengths always produces a 3-year CRI.

You can also perform the split, exchange, and merge operations using the AWS Command Line Interface (CLI) and the EC2 APIs.

Available Now
All of the functions and the 1-year CRIs described in this post are available now and you can start using them today.

Jeff;

Съд на ЕС: отговорност на оператора на фенстраница във Фейсбук

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/05/fb-3/

Стана известно заключението на Генералния адвокат Бот по дело C−210/16 Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

срещу Wirtschaftsakademie Schleswig-Holstein GmbH в присъствието на Facebook Ireland Ltd.

„Преюдициално запитване — Директива 95/46/ЕО — Членове 2, 4 и 28 — Защита на физическите лица при обработване на лични данни и свободно движение на такива данни — Разпореждане за деактивиране на фенстраница в социалната мрежа Facebook — Понятие „администратор“ — Отговорност на оператора на фенстраница — Съвместна отговорност — Приложимо национално право — Обхват на правомощията за намеса на надзорните органи“

Запитването е отправено в рамките на спор между Wirtschaftsakademie Schleswig-Holstein GmbH, частноправно дружество, специализирано в областта на образованието  и  органа за защита на данните на Шлезвиг-Холщайн („ULD“), във връзка със законосъобразността на разпореждане, прието от последно посочения орган срещу Wirtschaftsakademie, с което се иска деактивиране на „фенстраница“ (Fanpage), хоствана на сайта на Facebook Ireland Ltd (наричано по-нататък „Facebook Ireland“).

Това разпореждане е мотивирано от твърдяното нарушение на разпоредбите на германското право за транспониране на Директива 95/46, по-специално поради факта, че посетителите на дадена фенстраница не са информирани за това, че техните лични данни се събират от социалната мрежа Facebook благодарение на „бисквитки“, които се разполагат на техния твърд диск, като това събиране се извършва с цел да се изготвят статистически данни за посетителите, които са предназначени за оператора на посочената страница, и за да се предостави възможност на Facebook да разпространява целеви реклами.

Надзорните органи на няколко държави  от ЕС са решили през последните месеци да наложат глоби на Facebook за нарушаване на правилата за защита на личните данни на неговите потребители – на 11 септември 2017 г. Agencia española de protección de datos (испанската Агенция за защита на данните) е обявила, че налага глоба в размер на 1,2 милиона евро на Facebook Inc. Преди това, на 27 април 2017 г. Commission nationale de l’informatique et des libertés (Националната комисия по въпросите на информатиката и свободите, CNIL, Франция) приема решение срещу дружествата Facebook Inc. и Facebook Ireland, като при условията на солидарна отговорност им налага имуществена санкция в размер на 150 000 EUR.

Разглежданото дело ще даде възможност на Съда да уточни обхвата на правомощията за намеса, с които разполага надзорен орган като ULD при обработване на лични данни, включващо участието на няколко субекта.

Преюдициалните въпроси

Заключението:

„1)      Член 2, буква г) от Директива 95/46/ЕО на Европейския парламент и на Съвета от 24 октомври 1995 година за защита на физическите лица при обработването на лични данни и за свободното движение на тези данни, изменена с Регламент (ЕО) № 1882/2003 на Европейския парламент и на Съвета от 29 септември 2003 г., трябва да се тълкува в смисъл, че съгласно тази разпоредба за администратор следва да се счита операторът на фенстраница в социална мрежа като Facebook, що се отнася до етапа на обработване на лични данни, състоящ се в събирането от тази социална мрежа на данни относно лицата, които консултират тази страница, с оглед на изготвянето на статистически данни за посетителите на посочената страница.

2)      Член 4, параграф 1, буква а) от Директива 95/46, изменена с Регламент № 1882/2003, трябва да се тълкува в смисъл, че обработване на лични данни като разглежданото в главното производство, се извършва в контекста на дейностите на установен на територията на държава членка обект на администратора по смисъла на посочената разпоредба, когато предприятието, което управлява социална мрежа, създава в тази държава членка дъщерно дружество, чието предназначение е да осигури рекламирането и продажбата на рекламните пространства, предлагани от това предприятие, и чиято дейност е насочена към лицата, живеещи в тази държава членка.

3)      В положение като разглежданото в главното производство, при което към съответното обработване на лични данни се прилага националното право на държавата членка на надзорния орган, член 28, параграфи 1, 3 и 6 от Директива 95/46, изменена с Регламент № 1882/2003, трябва да се тълкува в смисъл, че този надзорен орган може да упражнява всички възложени му в съответствие с член 28, параграф 3 от посочената директива ефективни правомощия за намеса по отношение на администратора, включително когато администраторът е установен в друга държава членка или пък в трета държава.

4)      Член 28, параграфи 1, 3 и 6 от Директива 95/46, изменена с Регламент № 1882/2003, трябва да се тълкува в смисъл, че при обстоятелства като разглежданите в главното производство надзорният орган на държавата членка, в която се намира обектът на администратора, има право да упражнява самостоятелно правомощията си за намеса по отношение на този администратор и без да е длъжен предварително да поиска от надзорния орган на държавата членка, в която се намира посоченият администратор, да упражни своите правомощия“.

u Techcrunch

Filed under: EU Law, Media Law Tagged: данни, FB, съд на ес

Съд на ЕС: медийни концентрации

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/11/05/kpn19560/

Стана известно решение  на Общия съд по дело T‑394/15 KPN BV  (Netherlands),  v European Commission

 

Жалбоподателят KPN BV е активен в сектора на кабелните мрежи за телевизионни, широколентови интернет, фиксирани телефонни услуги и мобилни телекомуникационни услуги, по-специално в Нидерландия.

Liberty Global plc е международен кабелен оператор, който притежава и експлоатира кабелни мрежи, предлагащи телевизия, широколентов интернет, фиксирана телефония и мобилни телекомуникационни услуги в единадесет държави-членки на Европейския съюз и Швейцария. Г-н Джон Малоун, американски гражданин, притежава най-голямото миноритарно участие в Liberty Global.

Ziggo NV притежава и управлява широколентова кабелна мрежа, която обхваща повече от половината от територията на Нидерландия. Това предприятие предоставя цифрови и аналогови кабелни видео, широколентов интернет, мобилни телекомуникации и услуги за цифрова телефония (Voice over Internet Protocol). Ziggo притежава 50% от HBO Nederland.

На 10 октомври 2014 г. Комисията приема Решение C (2014) 7241, с което обявява концентрацията, включваща придобиването от Liberty Global на изключителен контрол над Ziggo, за съвместима с вътрешния пазар и със Споразумението за ЕИП (Дело COMP / M.7000 – Liberty Global / Ziggo) (ОВ 2015, C 145, стр. 7) .

KPN обжалва решението  на три правни основания –  явна грешка в преценката относно евентуалните вертикални последици на концентрацията на пазара на pay tv,  нарушение на задължението за анализ на евентуалните вертикални антиконкурентни ефекти на пазара на спортни телевизионни канали  и   явна грешка в преценката относно упражняването на решаващо влияние върху г-н Malone върху Liberty Global.

Съдът анализира второто основание – липсата на мотиви – и потвърждава, че обжалваното решение не съдържа достатъчен  анализ относно вертикалните ефекти, които биха произтекли от предложената концентрация.

В резултат отменя решението на ЕК.

Filed under: EU Law, Media Law Tagged: съд на ес

How to Prepare for AWS’s Move to Its Own Certificate Authority

Post Syndicated from Jonathan Kozolchyk original https://aws.amazon.com/blogs/security/how-to-prepare-for-aws-move-to-its-own-certificate-authority/

AWS Certificate Manager image

Transport Layer Security (TLS, formerly called Secure Sockets Layer [SSL]) is essential for encrypting information that is exchanged on the internet. For example, Amazon.com uses TLS for all traffic on its website, and AWS uses it to secure calls to AWS services.

An electronic document called a certificate verifies the identity of the server when creating such an encrypted connection. The certificate helps establish proof that your web browser is communicating securely with the website that you typed in your browser’s address field. Certificate Authorities, also known as CAs, issue certificates to specific domains. When a domain presents a certificate that is issued by a trusted CA, your browser or application knows it’s safe to make the connection.

In January 2016, AWS launched AWS Certificate Manager (ACM), a service that lets you easily provision, manage, and deploy SSL/TLS certificates for use with AWS services. These certificates are available for no additional charge through Amazon’s own CA: Amazon Trust Services. For browsers and other applications to trust a certificate, the certificate’s issuer must be included in the browser’s trust store, which is a list of trusted CAs. If the issuing CA is not in the trust store, the browser will display an error message (see an example) and applications will show an application-specific error. To ensure the ubiquity of the Amazon Trust Services CA, AWS purchased the Starfield Services CA, a root found in most browsers and which has been valid since 2005. This means you shouldn’t have to take any action to use the certificates issued by Amazon Trust Services.

AWS has been offering free certificates to AWS customers from the Amazon Trust Services CA. Now, AWS is in the process of moving certificates for services such as Amazon EC2 and Amazon DynamoDB to use certificates from Amazon Trust Services as well. Most software doesn’t need to be changed to handle this transition, but there are exceptions. In this blog post, I show you how to verify that you are prepared to use the Amazon Trust Services CA.

How to tell if the Amazon Trust Services CAs are in your trust store

The following table lists the Amazon Trust Services certificates. To verify that these certificates are in your browser’s trust store, click each Test URL in the following table to verify that it works for you. When a Test URL does not work, it displays an error similar to this example.

Distinguished name SHA-256 hash of subject public key information Test URL
CN=Amazon Root CA 1,O=Amazon,C=US fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 Test URL
CN=Amazon Root CA 2,O=Amazon,C=US 7f4296fc5b6a4e3b35d3c369623e364ab1af381d8fa7121533c9d6c633ea2461 Test URL
CN=Amazon Root CA 3,O=Amazon,C=US 36abc32656acfc645c61b71613c4bf21c787f5cabbee48348d58597803d7abc9 Test URL
CN=Amazon Root CA 4,O=Amazon,C=US f7ecded5c66047d28ed6466b543c40e0743abe81d109254dcf845d4c2c7853c5 Test URL
CN=Starfield Services Root Certificate Authority – G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US 2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92 Test URL
Starfield Class 2 Certification Authority 2ce1cb0bf9d2f9e102993fbe215152c3b2dd0cabde1c68e5319b839154dbb7f5 Test URL

What to do if the Amazon Trust Services CAs are not in your trust store

If your tests of any of the Test URLs failed, you must update your trust store. The easiest way to update your trust store is to upgrade the operating system or browser that you are using.

You will find the Amazon Trust Services CAs in the following operating systems (release dates are in parentheses):

  • Microsoft Windows versions that have January 2005 or later updates installed, Windows Vista, Windows 7, Windows Server 2008, and newer versions
  • Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 and newer versions
  • Red Hat Enterprise Linux 5 (March 2007), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
  • Ubuntu 8.10
  • Debian 5.0
  • Amazon Linux (all versions)
  • Java 1.4.2_12, Jave 5 update 2, and all newer versions, including Java 6, Java 7, and Java 8

All modern browsers trust Amazon’s CAs. You can update the certificate bundle in your browser simply by updating your browser. You can find instructions for updating the following browsers on their respective websites:

If your application is using a custom trust store, you must add the Amazon root CAs to your application’s trust store. The instructions for doing this vary based on the application or platform. Please refer to the documentation for the application or platform you are using.

AWS SDKs and CLIs

Most AWS SDKs and CLIs are not impacted by the transition to the Amazon Trust Services CA. If you are using a version of the Python AWS SDK or CLI released before February 5, 2015, you must upgrade. The .NET, Java, PHP, Go, JavaScript, and C++ SDKs and CLIs do not bundle any certificates, so their certificates come from the underlying operating system. The Ruby SDK has included at least one of the required CAs since June 10, 2015. Before that date, the Ruby V2 SDK did not bundle certificates.

Certificate pinning

If you are using a technique called certificate pinning to lock down the CAs you trust on a domain-by-domain basis, you must adjust your pinning to include the Amazon Trust Services CAs. Certificate pinning helps defend you from an attacker using misissued certificates to fool an application into creating a connection to a spoofed host (an illegitimate host masquerading as a legitimate host). The restriction to a specific, pinned certificate is made by checking that the certificate issued is the expected certificate. This is done by checking that the hash of the certificate public key received from the server matches the expected hash stored in the application. If the hashes do not match, the code stops the connection.

AWS recommends against using certificate pinning because it introduces a potential availability risk. If the certificate to which you pin is replaced, your application will fail to connect. If your use case requires pinning, we recommend that you pin to a CA rather than to an individual certificate. If you are pinning to an Amazon Trust Services CA, you should pin to all CAs shown in the table earlier in this post.

If you have comments about this post, submit them in the “Comments” section below. If you have questions about this post, start a new thread on the ACM forum.

– Jonathan

2017-10-26 policy routing с Linux

Post Syndicated from Vasil Kolev original https://vasil.ludost.net/blog/?p=3367

В последно време на няколко места по различни случаи ми се налага да подкарвам policy routing под Linux, та тук мисля да систематизирам защо и как.

1) Какво е policy routing

Съвсем просто, routing, който не се базира САМО на destination IP адрес. В linux това се реализира чрез правила (rules), които на база на нещо решават да се гледа друга routing таблица, не стандартната.

2) Защо ни трябва

Основният use case е когато имаме два или повече default route-а, и искаме да можем за трафик, който е дошъл от единия да излизаме навън пак през него. Примерът, който ще дам по-долу е с два internet доставчика, но при мен се налага като конфигурирам bgp с някой, да слагам policy routing за адресите, които са на самия link да си излизат от верния интерфейс, за да мога да вляза от там, ако нещо се е ошашкало по bgp-то.

3) Как се настройва за крайна машина

Примерът, който ще дам е какво правим, ако имаме два доставчика, които ще кръстя pesho и gosho (ако искате, PeshoNet и GoshoCom).

pesho ви е дал link, на който имате адрес 10.1.1.30/24 с default gw 10.1.1.1 и сте го вързали на eth0, gosho ви е дал 10.2.2.40/24 с default gw 10.2.2.254 и сте го вързали на eth1.

Давам настройките директно с команди, как да интегрирате това в настройките на дистрибуцията си варира твърде много (мога да кажа, че в debian с pre-up и down директиви в interfaces файла може да се направи цялото нещо).

Ако просто ги настроите директно, routing таблицата ще изглежда по следния начин:

~ # ip r
default via 10.1.1.1 dev eth0
default via 10.2.2.254 dev eth1
10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.30
10.2.2.0/24 dev eth1  proto kernel  scope link  src 10.2.2.40

Това никаква работа не върши, понеже ако отвън дойде пакет за 10.1.1.30, може да излезе от другия link и обратно, а това доставчиците никак не го обичат и филтрират. За това просто в тая таблица оставяте само единия от двата default-а и продължаваме нататък.

Първо, харесваме си числата 1 и 2, даваме 1 на pesho, 2 на gosho, и ги описваме в /etc/iproute2/rt_tables (там има и други неща, това са редовете за добавяне):


...
1 pesho
2 gosho
...

Смисълът от това е, че можем да пишем неща като ip r show table pesho вместо ip r show table 1.

Имайки тези таблици, ги попълваме с каквито пътища имаме:

ip route add 10.1.1.0/24 dev eth0 table pesho
ip route add default via 10.1.1.1 table pesho
ip route add 10.2.2.0/24 dev eth1 table gosho
ip route add default via 10.2.2.254 table gosho

И след това пишем самите правила:

ip rule add from 10.1.1.30 iif lo table pesho
ip rule add from 10.2.2.40 iif lo table gosho

Тук има нужда от малко обяснение – “iif lo” означава “идващи от локалната машина”, останалото е в общи линии просто – ако source адресът е този, гледай конкретната таблица.

До тук е setup-а, ако имате просто една машина и нищо повече…

4) Как се настройва при NAT

Какво правим, ако имаме отзад една мрежичка, да кажем стандартната 192.168.0.0/24, на eth7?

Като за начало, трябва да добавим тази мрежа и в другите две таблици:

for t in pesho gosho; do ip route add 192.168.0.0/24 dev eth7 table $p; done

(някой би написа командите, но ми се е налагало да правя това за 10 таблици и почва да става досадно)

Съответно, да речем, че си имате едни прости правила за nat, които казват, че маскирате трафика навън:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

и някакво правило, че имате някакво web сървърче навътре на 192.168.0.100 порт 8080:

iptables -t nat -A PREROUTING -d 10.1.1.30/32 -i eth0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.0.100:80
iptables -t nat -A PREROUTING -d 10.2.2.40/32 -i eth1 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.0.100:80

Тук за изходящите връзки, ако решите да смените през кой доставчик, съществуващите ще тръгнат да излизат през новия път (и няма да работят), а ако имате входящи от този, през който не ви е текущия default route, пак ще се опитват да излязат от грешното място, понеже маскирането се случва някъде след routing-а. Решението е т.нар. “CONNMARK”, с който може 1) да маркирате определени връзки, 2) маркировката да се пренася в/у пакетите, и после 3) по маркировката да решавате коя таблица да ползвате.

Това се случва в mangle:

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x1/0xffffffff
iptables -t mangle -A PREROUTING -i eth1 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x2/0xffffffff
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff

Тези неща се превеждат като “по единия интерфейс маркирай с 1, по другия с 2, на вход сипвай маркировката от connection-а в пакета (restore-mark), на изход сипвай от пакета на connection-а” (взех ги от един готов save-нат iptables, за това са с тия пълни маски, мисля, че по принцип не бяха нужни). Другото, което трябва е да добавим routing правила, които да взимат решение коя таблица се гледа:

ip rule add fwmark 0x1 table pesho
ip rule add fwmark 0x2 table gosho

5) Load balancing, failover, такива неща

Това е голяма гадост. Писал съм преди по темата за fail-over,като изключим gwping-а и може би една добавка ако той сменя връзката, понеже е умряла, да трепе всичкия state в conntrack-а, няма какво да добавя.

За load balancing бих препоръчал нещо сравнително статично, определени неща през единия доставчик и други през другия, с нещо, което ги трие, когато изпадне единия доставчик. Бях провеждал експеримент в initLab да правя 2 connection-а през единия доставчик и един през другия или някакви такива неща, резултатът беше доста неприятен.

ЕСПЧ: стандартите на отговорната журналистика са валидни и при сериозен обществен интерес

Post Syndicated from nellyo original https://nellyo.wordpress.com/2017/10/26/echr-fuchsmann/

На 19 октомври 2017 г. Съдът за правата на човека се произнесе по делото Fuchsmann v. Germany. В решението се обсъжда баланса между правата по чл.8 (личен живот) и чл.10 (свобода на изразяване) ЕКПЧ.

Борис Фуксман е собственик на телевизия в Киев.  Ню Йорк Таймс (електронно издание) публикува статия, в която се споменава подкуп за украинска администрация с цел получаването на лицензия за телевизионна дейност, също така споменават се  предполагаемите връзки на Фуксман с руската организирана престъпност и че на лицето е забранено да влиза в САЩ.

Онлайн версията е достъпна от Германия, засегнато е името на  гражданин на Германия, със случая се занимават съдилища в Германия. Фуксман твърди, че е оклеветен, но съдилищата стигат до извода, че има справедлив баланс между свободата на изразяване на изданието и защитата на личния живот на бизнесмена. В последна сметка Фуксман завежда дело пред ЕСПЧ.

Решението

Съдът е установил наличие на обществен интерес, данните са изнесени в светлината на корупционни скандали в Ню Йорк.

Съдът приема, че Фуксман е публична фигура в качеството си на германски предприемач, работещ глобално в областта на медиите.

Съдът приема, че публикацията има достатъчна фактическа основа – основен  източник на изявленията  е вътрешен доклад на ФБР, подкрепен от други доклади. Журналистът е основал своите статии на достатъчно надеждни източници, при това не само на въпросния доклад. Той е действал в съответствие с журналистическите стандарти за работа с източници. В това отношение ЕСПЧ утвърждава отново стандартите на отговорната журналистика:

Съдът отново заявява, че член 10 от Конвенцията не гарантира напълно свободна свобода на изразяване, дори и по отношение на пресата за въпроси от сериозен обществен интерес. Съгласно чл.10, параграф 2   свободата на изразяване е придружена от “задължения и отговорности”, които се отнасят и за медиите, дори по отношение на въпроси от сериозен обществен интерес. Поради тези “задължения и отговорности” защитата, предоставена от член 10 на журналистите във връзка с отразяването на въпроси от обществен интерес, е подчинена на условието те да действат добросъвестно, за да предоставят точна и надеждна информация в съответствие с етиката на журналистиката (вж. например Fressoz и Roire срещу Франция [GC], № 29183/95, § 54, ЕКПЧ 1999-I и Pedersen и Baadsgaard срещу Дания [GC], № 49017/99 , § 78, ЕКПЧ 2004-XI). [42]

Не се разкриват подробности от личния живот на лицето и лични данни.

Според ЕСПЧ националните органи са анализирали баланса на права в съответствие с практиката на Съда.  Необходими са сериозни мотиви, за да се промени оценката им. В случая няма такива мотиви, тъй като германският съд е постигнал разумен баланс между конкуриращите се права и е действал в рамките на своята свобода на преценка [54].

Няма нарушение на чл.8 ЕКПЧ.

Интересен момент в решението е акцентирането върху ролята на онлайн архивите за проучване на важни минали събития.

[…] описването на предполагаемия криминален произход на някои от участващите лица е било необходимо за разбирането на публикацията. Съдът също така взе предвид, че статията остава достъпна в онлайн архив на всекидневника. […] има признат обществен интерес не само от информацията за текущите събития, но и от възможността да се изследват събития от новата история.[16]

Filed under: Media Law Tagged: еспч, клевета, отговорна журналистика

Анатомия на соц-типа: Съветският човек в емиграция

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2092


Този запис е превод от блога на Андрей Шипилов – или, както казва той, неговото лично информационно средство. Благодаря на Вени Марковски, че ме насочи към него.

Оригиналът е тук. Ако знаете руски, прочетете него – преводът ми е бледа сянка. Ние нямаме съответствия на руските думи „совок“ и „ватник“, които да носят същите многозначимост и емоционален заряд.

Прав ли е Шипилов? Не зная, нямам много наблюдения върху руски емигранти. Но върху българските имам. Тези, които са успели да попият западната нормалната ценностна система, са изключително читави хора. Има обаче и неуспели – и те с точност покриват описанието тук. Човек лесно можеш да го извадиш от комунизма, но комунизмът от човека – понякога е трудно.

Понеже България с доста точност покрива описанието на Русия тук. Когато четете „Русия“, мислете „България“. Надали ще сбъркате много.

—-

За начало един виц, който отразява до немай-къде точно същността на тези редове:

Затворническа килия. Двама рецидивисти гледат по телевизора юбилейния концерт на Алла Пугачова. Единият отбелязва:

– Кат си помислиш само, Пугачова е на шейсет вече, а как само изглежда! Как ли се поддържа?

Вторият:

– Как как? Цял живот на свобода. И се храни здравословно – сланинка, маргаринче, тортички, пържолки…

И сам се сблъсквам с това, и непрекъснато чувам отвсякъде недоумяващи възгласи. Как така хората, дето са избягали на Запад от СССР и после от Русия, от същия този комунизъм, на Запад се превръщат в негови най-предани поклонници и пропагандисти?

Защо най-възторжените поддръжници на превземането на Крим и руската имперщина са бивши съветски и руски граждани, избягали на Запад? Защо след като избягат от комунизма, те го пренасят със себе си и се опитват да го налагат в сегашното си обкръжение?

(Бележка от преводача: Чувам понякога, че е „понеже там всъщност е зле“. Е като им е толкова зле там, защо не се връщат тук? Нямат пари за път ли, насила ли ги държат там или…?)

На практика всичко е простичко. Сядайте наоколо, ще ви обясня!

Мъдрият сенатор Маккейн беше нарекъл Русия страна-бензиностанция. Прав беше, само че беше сгрешил. Прав в смисъл, че съвременна Русия изобщо не е страна. А сгрешил, понеже я приемаше за бензиностанция.

Какво е бензиностанцията? За разлика от Русия е полезно и нужно нещо. Общото ѝ с Русия е само че и двете търгуват с петролни продукти.

Русия обаче не е бензиностанция. Русия е един огромен концлагер.

Да, да, знам. Често я сравняват с концлагер. Нищо ново не казвам.

Само че не я сравнявам! Не употребявам тази дума като епитет, нито в преносен смисъл. Русия е съвсем истински концлагер, маскиран като страна. В него няма граждани и правителство. Има затворници и лагерна администрация.

Преценете сами! Ако живеете в Русия, всеки от вас може във всеки момент да бъде лишен от собственост, свобода и живот. Просто по прищявка на лагерната администрация, без никаква вина от ваша страна, или пък повод.

Когато си купувате жилище или вила, имате ли каквато и да е гаранция, че те са наистина ваши? Че утре няма да дойдат и да ви кажат, че владеете това незаконно и трябва да се разделите с него? Или няма просто да ви ги съборят, понеже пречат на Някого?

Не сте ли чували от най-високопоставени усти изявления като „Никой няма право да се прикрива зад разни хартийки за собственост!“?

Когато започвате бизнес, убедени ли сте, че той е ваш? Че утре няма да ви го вземат, че няма да ви съборят лавката само защото на нейно място трябва да застане лавката на „по-правилен“ човек?

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

Че ако такъв „представител“ блъсне детето ви, няма в кръвта на детето да открият огромни количества алкохол? Че родственикът ви, който е бил блъснат на пешеходна пътека от кола „с лампа“, няма да се окаже сам виновен? И че ако потърсите справедливост, няма внезапно да ви претърсят, да открият наркотици и да ви вкарат в затвора?

Вие ли решавате дали ще ядете френски пармезан или турски зеленчуци, или го решава за вас лагерната администрация? Как и на какво ще бъде учено детето ви? От вас ли зависи дали ще бъде платено или не лечението на детето ви, ако не дай боже то се разболее тежко? Можете ли да решите дали ще получава обезболяващи страдащ от хронична болка ваш родител?

Искате да ме убедите, че всичко това са нормални отношения между граждани и правителство на една държава? Не. Нормални са, когато са между концлагеристи и лагерна администрация.

Както във всеки концлагер, и в Русия има неформална йерархия. За разлика от концлагерната, тя не се ограничава с няколко простички нива. Руската концлагерна йерархия е много по-многослойна и разклонена. Само дето това не променя същността ѝ.

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

Защото шофьорът е член на лагерната администрация, а академикът е просто концлагерист, ако и по-привилегирован от повечето.

Мястото в хранителната екосистема на руския концлагер се определя именно от положението в тази неформална концлагерно-криминална йерархия. Нито заплатата, нито името на длъжността, нито количеството собственост нямат никакво значение на фона на концлагерната йерархия.

Именно затова целият живот на човек в Русия се състои от постоянно отстояване на мястото си в тази йерархия. От ежедневни и ежеминутни опити да демонстрира на околните, че дори само за миг, но точно в този момент и тази точка на времето и пространството, той заема по-високо положение.

Вие дори не го забелязвате!

Тази демонстрация на позиции в лагерната йерархия до такава степен е част от живота на съветския човек (казвам „съветски“, а не „руски“, понеже този типаж е характерен далеч не само за Русия), станала е толкова обикновена и неразделна част от ежедневието, че човек не я осъзнава, не вижда в нея нищо особено и не разбира как би могло да е иначе.

Лекарят в поликлиниката с чувство на гордо удовлетворение ще откаже да ви приеме, понеже сте закъснели десет минути. Не защото е зает или има други пациенти, а защото се е намерил формален повод да ви демонстрира, че той е „по-главният“.

Вие ще тичате към току-що пуснатата каса в супермаркета, разблъсквайки с лакти околните, не защото бързате и е важно да спестите една минута. А защото, когато се окажете пред всички, вие ще демонстрирате „предимство“, и като че ли ще заемете за миг мъничко по-високо стъпало в йерархията.

Касиерът в същия супермаркет високомерно ще ви дръпне лекция по повод… по какъвто и да е повод, който успее да намери, за да ви покаже, че точно тук и в този момент той, като длъжностно лице в супермаркета, стои над вас.

Вие няма да пропуснете другата кола, с която сте се засрещнали на тясна уличка, не защото ви е работа да ѝ попречите да мине, или ще спечелите нещо от това. А защото отстъпите ли път на някого, с това ще принизите в собствените си очи позицията си в концлагерната йерархия.

Ще се хвърляте да „наливате акъл“ на отнелия ви предимство на пътя джигит не защото разчитате с това да му помогнете да се поправи, а за да му покажете, че мястото му в йерархията е под вашето.

Съветските хора почти никога не се извиняват и не признават грешките си. Защото да се окажеш неправ е неприемливо! Признавайки грешката си, ти се съгласяваш с това да заемеш по-ниско място в йерархията!

Съветските хора не съобщават в полицията, когато някой нарушава закона. Не защото те одобряват и поддържат нарушаването на закона, а понеже да донасяш по концлагерните мерки е неприемливо. Концлагеристите трябва да се подкрепят един друг в отношенията с лагерната администрация. Ако съобщиш за престъпление на съседа, ти с това предаваш братството на концлагеристите и минаваш на страната на администрацията, ставаш „слухар“.

И вие живеете в този концлагер и ежедневно и ежеминутно вършите тези идиотски постъпки, без да се замисляте за същността им. Целият ви живот, даже ако не го осъзнавате, е подчинен на тази една цел – да обозначите място в лагерната йерархия и да дадете на околните да разберат, че вие сте в нея по-високо от тях. Повтарям – вие даже не го осъзнавате. Не го осъзнавате, понеже никога не сте живели в общество без концлагерна йерархия и не разбирате, че е възможно иначе.

В западния свят също е пълно с най-различни йерархии – служебни, професионални, корпоративни, семейни. Там обаче няма такава глобална йерархия, която да пронизва цялото общество отгоре додолу. Няма концлагерна йерархия, понеже там е не концлагер, а страна.

Там има не лагерна администрация и концлагеристи, а правителство и граждани. И ако случайно правителството там вземе да реши да определя могат ли гражданите да ядат пармезан или не, тогава… всъщност, няма нищо да стане, понеже на никой и през ум няма да му мине, че подобно нещо е работа на правителството. То не е. Работа е на лагерната администрация.

Проблемът на съветския човек е, че когато се окаже на Запад, той продължава да запазва този си шаблон на поведение. Продължава да демонстрира на околните мястото си в лагерната йерархия. Само че йерархията я няма! Той демонстрира място, а йерархията я няма! И той не разбира какво става. Нали дори не осъзнава, че това което върши, е демонстриране на място в йерархия. Просто се държи така, както е свикнал при соца. И реакцията на околните на неговото поведение го хвърля в смут.

Съветският човек хуква към току-що пуснатата каса в супермаркета, а околните вместо да му преграждат пътя и да се опитват да го изместят, му отстъпват път с любезни усмивки. Те виждат нещо съвсем различно от това, което вижда съветският човек. В Русия публиката, която вижда някой да се прережда, не го пуска – това е неприемливо, който те предреди, те е изместил в йерархията! А западнякът вижда, че човекът бърза, и значи е хубаво да му бъде отстъпен път! Напълно логична реакция.

Съветският човек обаче възприема това като слабост. След като ме пускат, мисли си той, значи са слабаци. значи ми отстъпват място в йерархията, и трябва успехът да бъде закрепен! И започва да „закрепва“ успеха си, и този път получава категоричен отпор. И много болезнен.

Защото като „закрепваш успеха“, е много лесно да прекрачиш границата, която разделя „демонстрация на място в йерархията“ от „нарушаване на правата на другите“. И соц-типът винаги я прекрачва. Той нито разбира местните реалности, нито се опитва да ги разбере. Нито пък, между другото, разбира какво е това „правата на другите“!

Само че западният човек може да не разбира какво е „борба за място в йерархията“, поради липсата на такава в обществото му, но фактът на нарушаване на правата му го разбира отлично. А умението да се сражава за правата си той го е попил с млякото на майка си, която пък е получила това умение от много поколения свободни предци.

Няколко картинки от натура, на които ми се е налагало да бъда свидетел:

Пристига руски юнак на чуждото море да се попече на слънце, и най-напред демонстрира на всички околни мястото си в йерархията по най-простия и достъпен способ – наема яка лимузина за четиристотин евро на денонощие. И я настъпва по местния аутобан.

Кажете обаче, кой мухльо ще се влачи със сто и двайсет по такъв разкошен аутобан с такава яка кола? А пък не можеш да я настъпиш – непрекъснато ти се мотаят отпред таратайките на разни аборигени. И когато един местен съвсем прекалява – не ще да отбие на банкета и да му освободи пътя – нашият герой решава по руски обичай да му преподаде урок. Задминава го, завива рязко пред него и се изправя на спирачките! Дръпне малко напред – пак на спирачките! И е много учуден, когато на изхода на магистралата го спира пътна полиция.

Какво са обаче някакви западни ченгета пред руския герой! Знае си той мястото в йерархията, то е много над разните там нобелови лауреати. За негово учудване обаче, опитът да сложи досадните куки на мястото им приключва с тримесечен престой в кауша. Почти на брега на морето, само дето не на плажа, а зад решетките.

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

– Ти това място не го използваш, значи е свободно и ще паркирам на него аз. Защото така ми е удобно, защо!

Гледа съветският човек как собственикът си тръгва, радва се колко лесно е показал на тоя мухльо къде му е мястото в йерархията, прибира се, но след десет минути покоя му го нарушават полицаи. Дошли да му съставят протокол за незаконно навлизане в частна собственост. Разбирайки, че посещението на полицаите го е свалило по йерархичната стълбица чак додолу, съветският човек отива при собственика на паркомястото, за да възстановява изгубените позиции и да обясни на този урод, че читавите момци не тропат на ченгетата. И отново го навестяват полицаите, но този път след протокола следва посещение в съда и депортиране.

Разбира се, случаи с толкова екстремален завършек като затвор или депортация са редки. Обикновено сраженията, които водят соц-типовете на Запад за място в несъществуващата йерархия, са много по-дребни и получените уроци не са толкова болезнени. Неизменно обаче остава едно. Соц-типът се опитва да заеме място в местната йерархия – и се проваля! Пак се опитва да заеме място – пак се проваля!

Той не разбира, че причината за провала е, че там просто не съществува концлагерна йерархия. Той възприема всеки свой неуспешен опит да заеме място в нея като спускане в нея. И накрая в един момент почва да се чувства на дъното ѝ.

Тогава на него (в представите му) му остава само едно – да се прилепи към някоя яка глутница. Ако не може личният му статут, поне статутът на глутницата му да бъде по-висок. Само че бедата продължава – там не само концлагерни йерархии няма, ама май и вълчи глутници също.

И тогава погледът му се обръща към напуснатата родина. Да, той е избягал от този концлагер, но в него поне е имал някакъв статус, ако и не висок. Все пак е бил малко над дъното, а не точно на него. И… я как само се плашат тук всички от Путин! Я как само Русия огъва де когото свари! Сирия! Крим е наш! Значи Русия е яка глутница! И щом съм руснак, значи съм член на тази глутница!

Ей, вие наоколо, я ме чуйте! Аз не съм ви тукашната последна дупка на кавала, както си мислите! Аз съм член на яка глутница, уважавайте ме! Ама защо пак не ме уважавате? Като дойде Путин, ще ви даде да разберете! Ей, Вова, я ги постави тези тук на място!

Попреувеличено е малко, но тъй като живея на Запад, доста пъти съм виждал този процес. И уверявам ви, в основата на целия този „кримнашизъм“ и „великорусизъм“ сред дошлите на Запад е само желанието да демонстрират на околните принадлежността си към силна глутница. Нищо друго.

Миналия уикенд бях свидетел как един бивш съветски експат, а сега просто емигрирал ватенкаджия, започна да се възхищава в компанията на себеподобни от „великия Путин“ и „Крим е наш“. И изведнъж бая грубичко го сложиха на мястото му: „Ти пък какво отношение имаш към това, нали не си руски гражданин?“

Ще рече простичко: „Не се притривай към силната ни глутница, ти не си неин член!“

Automating Security Group Updates with AWS Lambda

Post Syndicated from Ian Scofield original https://aws.amazon.com/blogs/compute/automating-security-group-updates-with-aws-lambda/

Customers often use public endpoints to perform cross-region replication or other application layer communication to remote regions. But a common problem is how do you protect these endpoints? It can be tempting to open up the security groups to the world due to the complexity of keeping security groups in sync across regions with a dynamically changing infrastructure.

Consider a situation where you are running large clusters of instances in different regions that all require internode connectivity. One approach would be to use a VPN tunnel between regions to provide a secure tunnel over which to send your traffic. A good example of this is the Transit VPC Solution, which is a published AWS solution to help customers quickly get up and running. However, this adds additional cost and complexity to your solution due to the newly required additional infrastructure.

Another approach, which I’ll explore in this post, is to restrict access to the nodes by whitelisting the public IP addresses of your hosts in the opposite region. Today, I’ll outline a solution that allows for cross-region security group updates, can handle remote region failures, and supports external actions such as manually terminating instances or adding instances to an existing Auto Scaling group.

Solution overview

The overview of this solution is diagrammed below. Although this post covers limiting access to your instances, you should still implement encryption to protect your data in transit.

If your entire infrastructure is running in a single region, you can reference a security group as the source, allowing your IP addresses to change without any updates required. However, if you’re going across the public internet between regions to perform things like application-level traffic or cross-region replication, this is no longer an option. Security groups are regional. When you go across regions it can be tempting to drop security to enable this communication.

Although using an Elastic IP address can provide you with a static IP address that you can define as a source for your security groups, this may not always be feasible, especially when automatic scaling is desired.

In this example scenario, you have a distributed database that requires full internode communication for replication. If you place a cluster in us-east-1 and us-west-2, you must provide a secure method of communication between the two. Because the database uses cloud best practices, you can add or remove nodes as the load varies.

To start the process of updating your security groups, you must know when an instance has come online to trigger your workflow. Auto Scaling groups have the concept of lifecycle hooks that enable you to perform custom actions as the group launches or terminates instances.

When Auto Scaling begins to launch or terminate an instance, it puts the instance into a wait state (Pending:Wait or Terminating:Wait). The instance remains in this state while you perform your various actions until either you tell Auto Scaling to Continue, Abandon, or the timeout period ends. A lifecycle hook can trigger a CloudWatch event, publish to an Amazon SNS topic, or send to an Amazon SQS queue. For this example, you use CloudWatch Events to trigger an AWS Lambda function that updates an Amazon DynamoDB table.

Component breakdown

Here’s a quick breakdown of the components involved in this solution:

• Lambda function
• CloudWatch event
• DynamoDB table

Lambda function

The Lambda function automatically updates your security groups, in the following way:

1. Determines whether a change was triggered by your Auto Scaling group lifecycle hook or manually invoked for a “true up” functionality, which I discuss later in this post.
2. Describes the instances in the Auto Scaling group and obtain public IP addresses for each instance.
3. Updates both local and remote DynamoDB tables.
4. Compares the list of public IP addresses for both local and remote clusters with what’s already in the local region security group. Update the security group.
5. Compares the list of public IP addresses for both local and remote clusters with what’s already in the remote region security group. Update the security group
6. Signals CONTINUE back to the lifecycle hook.

CloudWatch event

The CloudWatch event triggers when an instance passes through either the launching or terminating states. When the Lambda function gets invoked, it receives an event that looks like the following:

{
	"account": "123456789012",
	"region": "us-east-1",
	"detail": {
		"LifecycleHookName": "hook-launching",
		"AutoScalingGroupName": "",
		"LifecycleActionToken": "33965228-086a-4aeb-8c26-f82ed3bef495",
		"LifecycleTransition": "autoscaling:EC2_INSTANCE_LAUNCHING",
		"EC2InstanceId": "i-017425ec54f22f994"
	},
	"detail-type": "EC2 Instance-launch Lifecycle Action",
	"source": "aws.autoscaling",
	"version": "0",
	"time": "2017-05-03T02:20:59Z",
	"id": "cb930cf8-ce8b-4b6c-8011-af17966eb7e2",
	"resources": [
		"arn:aws:autoscaling:us-east-1:123456789012:autoScalingGroup:d3fe9d96-34d0-4c62-b9bb-293a41ba3765:autoScalingGroupName/"
	]
}

DynamoDB table

You use DynamoDB to store lists of remote IP addresses in a local table that is updated by the opposite region as a failsafe source of truth. Although you can describe your Auto Scaling group for the local region, you must maintain a list of IP addresses for the remote region.

To minimize the number of describe calls and prevent an issue in the remote region from blocking your local scaling actions, we keep a list of the remote IP addresses in a local DynamoDB table. Each Lambda function in each region is responsible for updating the public IP addresses of its Auto Scaling group for both the local and remote tables.

As with all the infrastructure in this solution, there is a DynamoDB table in both regions that mirror each other. For example, the following screenshot shows a sample DynamoDB table. The Lambda function in us-east-1 would update the DynamoDB entry for us-east-1 in both tables in both regions.

By updating a DynamoDB table in both regions, it allows the local region to gracefully handle issues with the remote region, which would otherwise prevent your ability to scale locally. If the remote region becomes inaccessible, you have a copy of the latest configuration from the table that you can use to continue to sync with your security groups. When the remote region comes back online, it pushes its updated public IP addresses to the DynamoDB table. The security group is updated to reflect the current status by the remote Lambda function.

 

Walkthrough

Note: All of the following steps are performed in both regions. The Launch Stack buttons will default to the us-east-1 region.

Here’s a quick overview of the steps involved in this process:

1. An instance is launched or terminated, which triggers an Auto Scaling group lifecycle hook, triggering the Lambda function via CloudWatch Events.
2. The Lambda function retrieves the list of public IP addresses for all instances in the local region Auto Scaling group.
3. The Lambda function updates the local and remote region DynamoDB tables with the public IP addresses just received for the local Auto Scaling group.
4. The Lambda function updates the local region security group with the public IP addresses, removing and adding to ensure that it mirrors what is present for the local and remote Auto Scaling groups.
5. The Lambda function updates the remote region security group with the public IP addresses, removing and adding to ensure that it mirrors what is present for the local and remote Auto Scaling groups.

Prerequisites

To deploy this solution, you need to have Auto Scaling groups, launch configurations, and a base security group in both regions. To expedite this process, this CloudFormation template can be launched in both regions.

Step 1: Launch the AWS SAM template in the first region

To make the deployment process easy, I’ve created an AWS Serverless Application Model (AWS SAM) template, which is a new specification that makes it easier to manage and deploy serverless applications on AWS. This template creates the following resources:

• A Lambda function, to perform the various security group actions
• A DynamoDB table, to track the state of the local and remote Auto Scaling groups
• Auto Scaling group lifecycle hooks for instance launching and terminating
• A CloudWatch event, to track the EC2 Instance-Launch Lifecycle-Action and EC2 Instance-terminate Lifecycle-Action events
• A pointer from the CloudWatch event to the Lambda function, and the necessary permissions

Download the template from here or click to launch.

Upon launching the template, you’ll be presented with a list of parameters which includes the remote/local names for your Auto Scaling Groups, AWS region, Security Group IDs, DynamoDB table names, as well as where the code for the Lambda function is located. Because this is the first region you’re launching the stack in, fill out all the parameters except for the RemoteTable parameter as it hasn’t been created yet (you fill this in later).

Step 2: Test the local region

After the stack has finished launching, you can test the local region. Open the EC2 console and find the Auto Scaling group that was created when launching the prerequisite stack. Change the desired number of instances from 0 to 1.

For both regions, check your security group to verify that the public IP address of the instance created is now in the security group.

Local region:

Remote region:

Now, change the desired number of instances for your group back to 0 and verify that the rules are properly removed.

Local region:

Remote region:

Step 3: Launch in the remote region

When you deploy a Lambda function using CloudFormation, the Lambda zip file needs to reside in the same region you are launching the template. Once you choose your remote region, create an Amazon S3 bucket and upload the Lambda zip file there. Next, go to the remote region and launch the same SAM template as before, but make sure you update the CodeBucket and CodeKey parameters. Also, because this is the second launch, you now have all the values and can fill out all the parameters, specifically the RemoteTable value.

 

Step 4: Update the local region Lambda environment variable

When you originally launched the template in the local region, you didn’t have the name of the DynamoDB table for the remote region, because you hadn’t created it yet. Now that you have launched the remote template, you can perform a CloudFormation stack update on the initial SAM template. This populates the remote DynamoDB table name into the initial Lambda function’s environment variables.

In the CloudFormation console in the initial region, select the stack. Under Actions, choose Update Stack, and select the SAM template used for both regions. Under Parameters, populate the remote DynamoDB table name, as shown below. Choose Next and let the stack update complete. This updates your Lambda function and completes the setup process.

 

Step 5: Final testing

You now have everything fully configured and in place to trigger security group changes based on instances being added or removed to your Auto Scaling groups in both regions. Test this by changing the desired capacity of your group in both regions.

True up functionality
If an instance is manually added or removed from the Auto Scaling group, the lifecycle hooks don’t get triggered. To account for this, the Lambda function supports a “true up” functionality in which the function can be manually invoked. If you paste in the following JSON text for your test event, it kicks off the entire workflow. For added peace of mind, you can also have this function fire via a CloudWatch event with a CRON expression for nearly continuous checking.

{
	"detail": {
		"AutoScalingGroupName": "<your ASG name>"
	},
	"trueup":true
}

Extra credit

Now that all the resources are created in both regions, go back and break down the policy to incorporate resource-level permissions for specific security groups, Auto Scaling groups, and the DynamoDB tables.

Although this post is centered around using public IP addresses for your instances, you could instead use a VPN between regions. In this case, you would still be able to use this solution to scope down the security groups to the cluster instances. However, the code would need to be modified to support private IP addresses.

 

Conclusion

At this point, you now have a mechanism in place that captures when a new instance is added to or removed from your cluster and updates the security groups in both regions. This ensures that you are locking down your infrastructure securely by allowing access only to other cluster members.

Keep in mind that this architecture (lifecycle hooks, CloudWatch event, Lambda function, and DynamoDB table) requires that the infrastructure to be deployed in both regions, to have synchronization going both ways.

Because this Lambda function is modifying security group rules, it’s important to have an audit log of what has been modified and who is modifying them. The out-of-the-box function provides logs in CloudWatch for what IP addresses are being added and removed for which ports. As these are all API calls being made, they are logged in CloudTrail and can be traced back to the IAM role that you created for your lifecycle hooks. This can provide historical data that can be used for troubleshooting or auditing purposes.

Security is paramount at AWS. We want to ensure that customers are protecting access to their resources. This solution helps you keep your security groups in both regions automatically in sync with your Auto Scaling group resources. Let us know if you have any questions or other solutions you’ve come up with!