Implementing data governance on AWS: Automation, tagging, and lifecycle strategy – Part 2

Post Syndicated from Omar Ahmed original https://aws.amazon.com/blogs/security/implementing-data-governance-on-aws-automation-tagging-and-lifecycle-strategy-part-2/

In Part 1, we explored the foundational strategy, including data classification frameworks and tagging approaches. In this post, we examine the technical implementation approach and key architectural patterns for building a governance framework.

We explore governance controls across four implementation areas, building from foundational monitoring to advanced automation. Each area builds on the previous one, so you can implement incrementally and validate as you go:

  • Monitoring foundation: Begin by establishing your monitoring baseline. Set up AWS Config rules to track tag compliance across your resources, then configure Amazon CloudWatch dashboards to provide real-time visibility into your governance posture. By using this foundation, you can understand your current state before implementing enforcement controls.
  • Preventive controls: Build proactive enforcement by deploying AWS Lambda functions that validate tags at resource creation time. Implement Amazon EventBridge rules to trigger real-time enforcement actions and configure service control policies (SCPs) to establish organization-wide guardrails that prevent non-compliant resource deployment.
  • Automated remediation: Reduce manual intervention by setting up AWS Systems Manager Automation Documents that respond to compliance violations. Configure automated responses that correct common issues like missing tags or improper encryption and implement classification-based security controls that automatically apply appropriate protections based on data sensitivity.
  • Advanced features: Extend your governance framework with sophisticated capabilities. Deploy data sovereignty controls to help ensure regulatory compliance across AWS Regions, implement intelligent lifecycle management to optimize costs while maintaining compliance, and establish comprehensive monitoring and reporting systems that provide stakeholders with clear visibility into your governance effectiveness.

Prerequisites

Before beginning implementation, ensure you have AWS Command Line Interface (AWS CLI) installed and configured with appropriate credentials for your target accounts. Set AWS Identity and Access Managment (IAM) permissions so that you can create roles, Lambda functions, and AWS Config rules. Finally, basic familiarity with AWS CloudFormation or Terraform will be helpful, because we’ll use CloudFormation throughout our examples.

Tag governance controls

Implementing tag governance requires multiple layers of controls working together across AWS services. These controls range from preventive measures that validate resources at creation to detective controls that monitor existing resources. This section describes each control type, starting with preventive controls that act as first line of defense.

Preventive controls

Preventive controls help ensure resources are properly tagged at creation time. By implementing Lambda functions triggered by AWS CloudTrail events, you can validate tags before resources are created, preventing non-compliant resources from being deployed:

# AWS Lambda function for preventive tag enforcement def enforce_resource_tags(event, context):     
	required_tags = ['DataClassification', 'DataOwner', 'Environment']          

	# Extract resource details from the event     
	resource_tags = 
event['detail']['requestParameters'].get('Tags', {})          

	# Validate required tags are present     
	missing_tags = [tag for tag in required_tags if tag not in resource_tags]          

	if missing_tags:
		# Send alert to security team
		# Log non-compliance for compliance reporting         
		raise Exception(f"Missing required tags: {missing_tags}")

	return {‘status’: ‘compliant’}

For complete, production-ready implementation, see Implementing Tag Policies with AWS Organizations and EventBridge event patterns for resource monitoring.

Organization-wide policy enforcement

AWS Organizations tag policies provide a foundation for consistent tagging across your organization. These policies define standard tag formats and values, helping to ensure consistency across accounts:

{   
    "tags": {     
        "DataClassification": {       
            "tag_key": {         
                "@@assign": "DataClassification"       
            },       
            "tag_value": {         
                "@@assign": ["L1", "L2", "L3"]       
            },       
            "enforced_for": {         
                "@@assign": [           
                    "s3:bucket",           
                    "ec2:instance",           
                    "rds:db",           
                    "dynamodb:table"         
                ]       
            }     
        }   
    } 
}

Detailed implementation guidance: Getting started with tag policies & Best practices for using tag policies

Tag-based access control

Tag-based access control gives you detailed permissions using attribute-based access control (ABAC). By using this approach, you can define permissions based on resource attributes rather than creating individual IAM policies for each use case:

{     
    "Version": "2012-10-17",     
    "Statement": [         
        {             
            "Effect": "Allow",             
            "Action": ["s3:GetObject", "s3:PutObject"],             
            "Resource": "*",             
            "Condition": {                 
                "StringEquals": {                     
                    "aws:ResourceTag/DataClassification": "L1",                     
                    "aws:ResourceTag/Environment": "Prod"                 
                }             
            }         
        }     
    ] 
}

Multi-account governance strategy

While implementing tag governance within a single account is straightforward, most organizations operate in a multi-account environment. Implementing consistent governance across your organization requires additional controls:

# This SCP prevents creation of resources without required tags 
OrganizationControls:   
	SCPPolicy:     
		Type: AWS::Organizations::Policy     
		Properties:       
			Content:         
				Version: "2012-10-17"         
				Statement:           
					- 	Sid: EnforceTaggingOnResources             
						Effect: Deny             
						Action:               
							- "ec2:RunInstances"               
							- "rds:CreateDBInstance"               
							- "s3:CreateBucket"             
						Resource: "*"             
						Condition:               
							'Null':                 
								'aws:RequestTag/DataClassification': true                 
								'aws:RequestTag/Environment': true

For more information, see implementation guidance for SCPs.

Integration with on-premises governance frameworks

Many organizations maintain existing governance frameworks for their on-premises infrastructure. Extending these frameworks to AWS requires careful integration and applicability analysis. The following example shows how to use AWS Service Catalog to create a portfolio of AWS resources that align with your on-premises governance standards.

# AWS Service Catalog portfolio for on-premises aligned resources 
ServiceCatalogIntegration:   
	Portfolio:     
		Type: AWS::ServiceCatalog::Portfolio     
		Properties:       
			DisplayName: Enterprise-Aligned Resources       
			Description: Resources that comply with existing governance framework       
			ProviderName: Enterprise IT   

# Product that maintains on-prem naming conventions and controls   
	CompliantProduct:     
		Type: AWS::ServiceCatalog::CloudFormationProduct     
		Properties:       
			Name: Compliant-Resource-Bundle       
			Owner: Enterprise Architecture       
			Tags:         
				- 	Key: OnPremMapping           
					Value: "EntArchFramework-v2"

Automating security controls based on classification

After data is classified, use these classifications to automate security controls and use AWS Config to track and validate that resources are properly tagged through defined rules that assess your AWS resource configurations, including a built-in required-tags rule. For non-compliant resources, you can use Systems Manager to automate the remediation process.

With proper tagging in place, you can implement automated security controls using EventBridge and Lambda. By using this combination, you can create a cost-effective and scalable infrastructure for enforcing security policies based on data classification. For example, when a resource is tagged as high impact, you can use EventBridge to trigger a Lambda function to enable required security measures.

def apply_security_controls(event, context):     
	resource_type = event['detail']['resourceType']     
	tags = event['detail']['tags']          

	if tags['DataClassification'] == 'L1':         
		# Apply Level 1 security controls         
		enable_encryption(resource_type)         
		apply_strict_access_controls(resource_type)         
		enable_detailed_logging(resource_type)     
	elif tags['DataClassification'] == 'L2':         
		# Apply Level 2 security controls         
		enable_standard_encryption(resource_type)         
		apply_basic_access_controls(resource_type)

This example automation applies security controls consistently, reducing human error and maintaining compliance. Code-based controls ensure policies match your data classification.

Implementation resources:

Data sovereignty and residency

Data sovereignty and residency requirements help you comply with regulations like GDPR. Such controls can be implemented to restrict data storage and processing to specific AWS Regions:

# Config rule for region restrictions 
AWSConfig:   
	ConfigRule:     
		Type: AWS::Config::ConfigRule     
		Properties:       
			ConfigRuleName: s3-bucket-region-check       
			Description: Checks if S3 buckets are in allowed regions       
			Source:         
				Owner: AWS         
				SourceIdentifier: S3_BUCKET_REGION       
			InputParameters:         
				allowedRegions:           
					- eu-west-1           
					- eu-central-1

Note: This example uses eu-west-1 and eu-central-1 because these Regions are commonly used for GDPR compliance, providing data residency within the European Union. Adjust these Regions based on your specific regulatory requirements and business needs. For more information, see Meeting data residency requirements on AWS and Controls that enhance data residence protection.

Disaster recovery integration with governance controls

While organizations often focus on system availability and data recovery, maintaining governance controls during disaster recovery (DR) scenarios is important for compliance and security. To implement effective governance in your DR strategy, start by using AWS Config rules to check that DR resources maintain the same governance standards as your primary environment:

AWSConfig:   
	ConfigRule:     
		Type: AWS::Config::ConfigRule     
		Properties:       
			ConfigRuleName: dr-governance-check       
			Description: Ensures DR resources maintain governance controls       
			Source:         
				Owner: AWS         
				SourceIdentifier: REQUIRED_TAGS       
			Scope:         
				ComplianceResourceTypes:           
					- "AWS::S3::Bucket"           
					- "AWS::RDS::DBInstance"           
					- "AWS::DynamoDB::Table"       
			InputParameters:         
				tag1Key: "DataClassification"         
				tag1Value: "L1,L2,L3"         
				tag2Key: "Environment"         
				tag2Value: "DR"

For your most critical data (classified as Level 1 in part 1 of this post), implement cross-Region replication while maintaining strict governance controls. This helps ensure that sensitive data remains protected even during failover scenarios:

Cross-Region:   
	ReplicationRule:     
		Type: AWS::S3::Bucket     
		Properties:       
			ReplicationConfiguration:         
				Role: !GetAtt ReplicationRole.Arn         
				Rules:           
					- 	Status: Enabled             
						TagFilters:               
							- 	Key: "DataClassification"                 
								Value: "L1"             
						Destination:               
							Bucket: !Sub "arn:aws:s3:::${DRBucket}"               
							EncryptionConfiguration:                 
								ReplicaKmsKeyID: !Ref DRKMSKey

Automated compliance monitoring

By combining AWS Config for resource compliance, CloudWatch for metrics and alerting, and Amazon Macie for sensitive data discovery, you can create a robust compliance monitoring framework that automatically detects and responds to compliance issues:

Figure 1: Compliance monitoring architecture

Figure 1: Compliance monitoring architecture

This architecture (shown in Figure 1) demonstrates how AWS services work together to provide compliance monitoring:

  • AWS Config, CloudTrail, and Macie monitor AWS resources
  • CloudWatch aggregates monitoring data
  • Alerts and dashboards provide real-time visibility

The following CloudFormation template implements these controls:

Resources:   
	EncryptionRule:     
		Type: AWS::Config::ConfigRule     
		Properties:       
			ConfigRuleName: s3-bucket-encryption-enabled       
			Source:         
				Owner: AWS         
				SourceIdentifier: 
S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED   

	MacieJob:     
		Type: AWS::Macie::ClassificationJob     
		Properties:       
			JobType: ONE_TIME       
			S3JobDefinition:         
				BucketDefinitions:           
				- 	AccountId: !Ref AWS::AccountId             
					Buckets:               
						- !Ref DataBucket       
				ScoreFilter:         
					Minimum: 75   

	SecurityAlarm:     
		Type: AWS::CloudWatch::Alarm     
		Properties:       
			AlarmName: UnauthorizedAccessAttempts       
			MetricName: UnauthorizedAPICount       
			Namespace: SecurityMetrics       
			Statistic: Sum       
			Period: 300       
			EvaluationPeriods: 1       
			Threshold: 3       
			AlarmActions:         
				- 	!Ref SecurityNotificationTopic       
			ComparisonOperator: GreaterThanThreshold

These controls provide real-time visibility into your security posture, automate responses to potential security events, and use Macie for sensitive data discovery and classification. For a complete monitoring setup, review List of AWS Config Managed Rules and Using Amazon CloudWatch dashboards.

Using AWS data lakes for governance

Modern data governance strategies often use data lakes to provide centralized control and visibility. AWS provides a comprehensive solution through the Modern Data Architecture Accelerator (MDAA), which you can use to help you rapidly deploy and manage data platform architectures with built-in security and governance controls. Figure 2 shows an MDAA reference architecture.

Figure 2: MDAA reference architecture

Figure 2: MDAA reference architecture

For detailed implementation guidance and source code, see Accelerate the Deployment of Secure and Compliant Modern Data Architectures for Advanced Analytics and AI.

Access patterns and data discovery

Understanding and managing access patterns is important for effective governance. Use CloudTrail and Amazon Athena to analyze access patterns:

SELECT   
	useridentity.arn,   
	eventname,   
	requestparameters.bucketname,   
	requestparameters.key,   
	COUNT(*) as access_count 
FROM cloudtrail_logs 
WHERE eventname IN ('GetObject', 'PutObject') 
GROUP BY 1, 2, 3, 4 
ORDER BY access_count DESC 
LIMIT 100;

This query helps identify frequently accessed data and unusual patterns in access behavior. These insights help you to:

  • Optimize storage tiers based on access frequency
  • Refine DR strategies for frequently accessed data
  • Identify of potential security risks through unusual access patterns
  • Fine-tune data lifecycle policies based on usage patterns

For sensitive data discovery, consider integrating Macie to automatically identify and protect PII across your data estate.

Machine learning model governance with SageMaker

As organizations advance in their data governance journey, many are deploying machine learning models in production, necessitating governance frameworks that extend to machine learning (ML) operations. Amazon SageMaker offers advanced tools that you can use to maintain governance over ML assets without impeding innovation.

SageMaker governance tools work together to provide comprehensive ML oversight:

  • Role Manager provides fine-grained access control for ML roles
  • Model Cards centralize documentation and lineage information
  • Model Dashboard offers organization-wide visibility into deployed models
  • Model Monitor automates drift detection and quality control

The following example configures SageMaker governance controls:

# Basic/High-level ML governance setup with role and monitoring SageMakerRole:   
	Type: AWS::IAM::Role   
	Properties:     
		# Allow SageMaker to use this role     
		AssumeRolePolicyDocument:       
			Statement:         
				- 	Effect: Allow           
					Principal:             
						Service: sagemaker.amazonaws.com           
					Action: sts:AssumeRole     
		# Attach necessary permissions     
		ManagedPolicyArns:       
				- 	arn:aws:iam::aws:policy/AmazonSageMakerFullAccess 

ModelMonitor:   
	Type: AWS::SageMaker::MonitoringSchedule   
	Properties:     
		# Set up hourly model monitoring     
		MonitoringScheduleName: hourly-model-monitor     
		ScheduleConfig:       
			ScheduleExpression: 'cron(0 * * * ? *)'  # Run hourly

This example demonstrates two essential governance controls: role-based access management for secure service interactions and automated hourly monitoring for ongoing model oversight. While these technical implementations are important, remember that successful ML governance requires integration with your broader data governance framework, helping to ensure consistent controls and visibility across your entire data and analytics ecosystem. For more information, see Model governance to manage permissions and track model performance.

Cost optimization through automated lifecycle management

Effective data governance isn’t just about security—it’s also about managing cost efficiently. Implement intelligent data lifecycle management based on classification and usage patterns, as shown in Figure 3:

Figure 3: Tag-based lifecycle management in Amazon S3

Figure 3: Tag-based lifecycle management in Amazon S3

Figure 3 illustrates how tags drive automated lifecycle management:

  • New data enters Amazon Simple Storage Service (Amazon S3) with the tag DataClassification: L2
  • Based on classification, the data starts in Standard/INTELLIGENT_TIERING
  • After 90 days, the data transitions to Amazon S3 Glacier storage for cost-effective archival
  • The RetentionPeriod tag (84 months) determines final expiration

Here’s the implementation of the preceding lifecycle rules:

LifecycleConfiguration:   
	Rules:     
		- 	ID: IntelligentArchive       
        	Status: Enabled       
            Transitions:         
				- 	StorageClass: INTELLIGENT_TIERING           
                	TransitionInDays: 0         
               	- 	StorageClass: GLACIER           
                	TransitionInDays: 90       
			Prefix: /data/       
			TagFilters:         
				- 	Key: DataClassification           
                	Value: L2     
   		- 	ID: RetentionPolicy       
        	Status: Enabled       
            ExpirationInDays: 2555  # 7 years       
            TagFilters:         
				- 	Key: RetentionPeriod           
                	Value: "84"  # 7 years in months

S3 Lifecycle automatically optimizes storage costs while maintaining compliance with retention requirements. For example, data initially stored in Amazon S3 Intelligent-Tiering automatically moves to Glacier after 90 days, significantly reducing storage costs while helping to ensure data remains available when needed. For more information, seeManaging the lifecycle of objects and Managing storage costs with Amazon S3 Intelligent-Tiering.

Conclusion

Successfully implementing data governance on AWS requires both a structured approach and adherence to key best practices. As you progress through your implementation journey, keep these fundamental principles in mind:

  • Start with a focused scope and gradually expand. Begin with a pilot project that addresses high-impact, low-complexity use cases. By using this approach, you can demonstrate quick wins while building experience and confidence in your governance framework.
  • Make automation your foundation. Apply AWS services such as Amazon EventBridge for event-driven responses, implement automated remediation for common issues, and create self-service capabilities that balance efficiency with compliance. This automation-first approach helps ensure scalability and consistency in your governance framework.
  • Maintain continuous visibility and improvement. Regular monitoring, compliance checks, and framework updates are essential for long-term success. Use feedback from your operations team to refine policies and adjust controls as your organization’s needs evolve.

Common challenges to be aware of:

  • Initial resistance to change from teams used to manual processes
  • Complexity in handling legacy systems and data
  • Balancing security controls with operational efficiency
  • Maintaining consistent governance across multiple AWS accounts and regions

For more information, implementation support, and guidance, see:

By following this approach and remaining mindful of potential challenges, you can build a robust, scalable data governance framework that grows with your organization while maintaining security, compliance, and efficient data operations.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Tushar Jain
Omar Ahmed

Omar Ahmed is an Auto and Manufacturing Solutions Architect who specializes in analytics. Omar’s journey in cloud computing began as an AWS data center operations technician, where he developed hands on infrastructure expertise. Outside of work, he enjoys motorsports, gaming, and swimming.
Will Black
Omar Mahmoud

Omar is a Solutions Architect helping small-medium businesses with their cloud journey. He specializes in Amazon Connect and next-gen developer services like Kiro. Omar began at AWS as a data center operations technician, gaining hands-on cloud infrastructure experience. Outside work, Omar enjoys gaming, hiking, and soccer.
Fritz Kunstler
Changil Jeong

Changil Jeong is a Solutions Architect at Amazon Web Services (AWS) partnering with Independent software vendor customers on their cloud transformation journey, with strong interests in security. He joined AWS as an SDE apprentice before transitioning to SA. Previously served in the U.S. Army as a financial and budgeting analyst and worked at a large IT consulting firm as a SaaS security analyst.
Brian Ruf
Paige Broderick

Paige Broderick is a Solutions Architect at Amazon Web Services (AWS) who works with Enterprise customers to help them achieve their AWS objectives. She specializes in cloud operations, focusing on governance and using AWS to develop smart manufacturing solutions. Outside of work, Paige is an avid runner and is likely training for her next marathon.

Implementing data governance on AWS: Automation, tagging, and lifecycle strategy – Part 1

Post Syndicated from Omar Ahmed original https://aws.amazon.com/blogs/security/implementing-data-governance-on-aws-automation-tagging-and-lifecycle-strategy-part-1/

Generative AI and machine learning workloads create massive amounts of data. Organizations need data governance to manage this growth and stay compliant. While data governance isn’t a new concept, recent studies highlight a concerning gap: a Gartner study of 300 IT executives revealed that only 60% of organizations have implemented a data governance strategy, with 40% still in planning stages or uncertain where to begin. Furthermore, a 2024 MIT CDOIQ survey of 250 chief data officers (CDOs) found that only 45% identify data governance as a top priority.

Although most businesses recognize the importance of data governance strategies, regular evaluation is important to ensure these strategies evolve with changing business needs, industry requirements, and emerging technologies. In this post, we show you a practical, automation-first approach to implementing data governance on Amazon Web Services (AWS) through a strategic and architectural guide—whether you’re starting at the beginning or improving an existing framework.

In this two-part series, we explore how to build a data governance framework on AWS that’s both practical and scalable. Our approach aligns with what AWS has identified as the core benefits of data governance:

  • Classify data consistently and automate controls to improve quality
  • Give teams secure access to the data they need
  • Monitor compliance automatically and catch issues early

In this post, we cover strategy, classification framework, and tagging governance—the foundation you need to get started. If you don’t already have a governance strategy, we provide a high-level overview of AWS tools and services to help you get started. If you have a data governance strategy, the information in this post can assist you in evaluating its effectiveness and understanding how data governance is evolving with new technologies.

In Part 2, we explore the technical architecture and implementation patterns with conceptual code examples, and throughout both parts, you’ll find links to production-ready AWS resources for detailed implementation.

Prerequisites

Before implementing data governance on AWS, you need the right AWS setup and buy-in from your teams.

Technical foundation

Start with a well-structured AWS Organizations setup for centralized management. Make sure AWS CloudTrail and AWS Config are enabled across accounts—you’ll need these for monitoring and auditing. Your AWS Identity and Access Management (IAM) framework should already define roles and permissions clearly.

Beyond these services, you’ll use several AWS tools for automation and enforcement. The AWS service quick reference table that follows lists everything used throughout this guide.

Organizational readiness

Successful implementation of data governance requires clear organizational alignment and preparation across multiple dimensions.

  • Define roles and responsibilities. Data owners classify data and approve access requests. Your platform team handles AWS infrastructure and builds automation, while security teams set controls and monitor compliance. Application teams then implement these standards in their daily workflows.
  • Document your compliance requirements. List the regulations you must follow—GDPR, PCI-DSS, SOX, HIPAA, or others. Create a data classification framework that aligns with your business risk. Document your tagging standards and naming conventions so everyone follows the same approach.
  • Plan for change management. Get executive support from leaders who understand why governance matters. Start with pilot projects to demonstrate value before rolling out organization-wide. Provide role-based training and maintain up-to-date governance playbooks. Establish feedback mechanisms so teams can report issues and suggest improvements.

Key performance indicators (KPIs) to monitor

To measure the effectiveness of your data governance implementation, track the following essential metrics and their target objectives.

  • Resource tagging compliance: Aim for 95%, measured through AWS Config rules with weekly monitoring, focusing on critical resources and sensitive data classifications.
  • Mean time to respond to compliance issues: Target less than 24 hours for critical issues. Tracked using CloudWatch metrics with automated alerting for high-priority non-compliance events
  • Reduction in manual governance tasks: Target reduction of 40% in the first year. Measured through automated workflow adoption and remediation success rates.
  • Storage cost optimization based on data classification: Target 15–20% reduction through intelligent tiering and lifecycle policies, monitored monthly by classification level.

With these technical and organizational foundations in place, you’re ready to implement a sustainable data governance framework.

AWS services used in this guide – Quick reference

This implementation uses the following AWS services. Some are prerequisites, while others are introduced throughout the guide.

Category

Services

Description

Foundation

AWS Organizations

Multi-account management structure that enables centralized policy enforcement and governance across your entire AWS environment.

AWS Identity and Access Management (IAM)

Controls who can access what resources through roles, policies, and permissions—the foundation of your security model.

Monitoring and auditing

AWS CloudTrail

Records every API call made in your AWS accounts, creating a complete audit trail of who did what, when, and from where.

AWS Config

Continuously monitors resource configurations and evaluates them against rules you define (such as requiring that all S3 buckets much be encrypted). When it finds resources that don’t meet your rules, it flags them as non-compliant so you can fix them manually or automatically.

Amazon CloudWatch

Aggregates metrics, logs, and events from across AWS for real-time monitoring, dashboards, and automated alerting on governance non-compliance.

Automation and enforcement

Amazon EventBridge

Acts as a central notification system that watches for specific events in your AWS environment (such as when an S3 bucket has been created) and automatically triggers actions in response (such as by running a Lambda function to check if it has the required tags). Think of it as an if this happens, then do that automation engine.

AWS Lambda

Runs your governance code (tag validation, security controls, remediation) in response to events without managing servers.

AWS Systems Manager

Automates operational tasks across your AWS resources. In governance, it’s primarily used to automatically fix non-compliant resources—for example, if AWS Config detects an unencrypted database, Systems Manager can run a pre-defined script to enable encryption without manual intervention.

Data protection

Amazon Macie

Uses machine learning to automatically discover, classify, and protect sensitive data like personal identifiable information (PII) across your S3 buckets.

AWS Key Management Service (AWS KMS)

Manages encryption keys for protecting data at rest, essential for high-impact data classifications.

Analytics & Insights

Amazon Athena

Serverless query service that analyzes data in Amazon S3 using SQL—perfect for querying CloudTrail logs to understand access patterns.

Standardization

AWS Service Catalog

Creates catalogs of pre-approved, governance-compliant resources that teams can deploy through self-service.

ML Governance

Amazon SageMaker

Provides specialized tools for governing machine learning operations including model monitoring, documentation, and access control.

Understanding the data governance challenge

Organizations face complex data management challenges, from maintaining consistent data classification to ensuring regulatory compliance across their environments. Your strategy should maintain security, ensure compliance, and enable business agility through automation. While this journey can be complex, breaking it down into manageable components makes it achievable.

The foundation: Data classification framework

Data classification is a foundational step in cybersecurity risk management and data governance strategies. Organizations should use data classification to determine appropriate safeguards for sensitive or critical data based on their protection requirements. Following the NIST (National Institute of Standards and Technology) framework, data can be categorized based on the potential impact to confidentiality, integrity, and availability of information systems:

  • High impact: Severe or catastrophic adverse effect on organizational operations, assets, or individuals
  • Moderate impact: Serious adverse effect on organizational operations, assets, or individuals
  • Low impact: Limited adverse effect on organizational operations, assets, or individuals

Before implementing controls, establishing a clear data classification framework is essential. This framework serves as the backbone of your security controls, access policies, and automation strategies. The following is an example of how a company subject to the Payment Card Industry Data Security Standard (PCI-DSS) might classify data:

  • Level 1 – Most sensitive data:
    • Examples: Financial transaction records, customer PCI data, intellectual property
    • Security controls: Encryption at rest and in transit, strict access controls, comprehensive audit logging
  • Level 2 – Internal use data:
    • Examples: Internal documentation, proprietary business information, development code
    • Security controls: Standard encryption, role-based access control
  • Level 3 – Public data:
    • Examples: Marketing materials, public documentation, press releases
    • Security controls: Integrity checks, version, control

To help with data classification and tagging, AWS created AWS Resource Groups, a service that you can use to organize AWS resources into groups using criteria that you define as tags. If you’re using multiple AWS accounts across your organization, AWS Organizations supports tag policies, which you can use to standardize the tags attached to the AWS resources in an organization’s account. The workflow for using tagging is shown in Figure 1. For more information, see Guidance for Tagging on AWS.

Figure 1: Workflow for tagging on AWS for a multi-account environment

Figure 1: Workflow for tagging on AWS for a multi-account environment

Your tag governance strategy

A well-designed tagging strategy is fundamental to automated governance. Tags not only help organize resources but also enable automated security controls, cost allocation, and compliance monitoring.

Figure 2: Tag governance workflow

Figure 2: Tag governance workflow

As shown in Figure 2, tag policies use the following process:

  1. AWS validates tags when you create resources.
  2. Non-compliant resources trigger automatic remediation, while compliant resources deploy normally.
  3. Continuous monitoring catches variation from your policies.

The following tagging strategy enables automation:

{   
    "MandatoryTags": {     
        "DataClassification": ["L1", "L2", "L3"],     
        "DataOwner": "<Department/Team Name>",     
        "Compliance": ["PCI", "SOX", "GDPR", "None"],     
        "Environment": ["Prod", "Dev", "Test", "Stage"],     
        "CostCenter": "<Business Unit Code>"   
    },   
    "OptionalTags": {     
        "BackupFrequency": ["Daily", "Weekly", "Monthly"],     
        "RetentionPeriod": "<Time in Months>",     
        "ProjectCode": "<Project Identifier>",     
        "DataResidency": "<Region/Country>"   
    } 
}

While AWS Organizations tag policies provide a foundation for consistent tagging, comprehensive tag governance requires additional enforcement mechanisms, which we explore in detail in Part 2.

Conclusion

This first part of the two-part series established the foundational elements of implementing data governance on AWS, covering data classification frameworks, effective tagging strategies, and organizational alignment requirements. These fundamentals serve as building blocks for scalable and automated governance approaches. Part 2 focuses on technical implementation and architectural patterns, including monitoring foundations, preventive controls, and automated remediation. The discussion extends to tag-based security controls, compliance monitoring automation, and governance integration with disaster recovery strategies. Additional topics include data sovereignty controls and machine learning model governance with Amazon SageMaker, supported by AWS implementation examples.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Tushar Jain
Omar Ahmed

Omar Ahmed is an Auto and Manufacturing Solutions Architect who specializes in analytics. Omar’s journey in cloud computing began as an AWS data center operations technician, where he developed hands on infrastructure expertise. Outside of work, he enjoys motorsports, gaming, and swimming.
Will Black
Omar Mahmoud

Omar is a Solutions Architect helping small-medium businesses with their cloud journey. He specializes in Amazon Connect and next-gen developer services like Kiro. Omar began at AWS as a data center operations technician, gaining hands-on cloud infrastructure experience. Outside work, Omar enjoys gaming, hiking, and soccer.
Fritz Kunstler
Changil Jeong

Changil Jeong is a Solutions Architect at Amazon Web Services (AWS) partnering with Independent software vendor customers on their cloud transformation journey, with strong interests in security. He joined AWS as an SDE apprentice before transitioning to SA. Previously served in the U.S. Army as a financial and budgeting analyst and worked at a large IT consulting firm as a SaaS security analyst.
Brian Ruf
Paige Broderick

Paige Broderick is a Solutions Architect at Amazon Web Services (AWS) who works with Enterprise customers to help them achieve their AWS objectives. She specializes in cloud operations, focusing on governance and using AWS to develop smart manufacturing solutions. Outside of work, Paige is an avid runner and is likely training for her next marathon.

Simplify network segmentation for AWS Outposts racks with multiple local gateway routing domains

Post Syndicated from Brianna Rosentrater original https://aws.amazon.com/blogs/compute/simplify-network-segmentation-for-aws-outposts-racks-with-multiple-local-gateway-routing-domains/

AWS now supports multiple local gateway (LGW) routing domains on AWS Outposts racks to simplify network segmentation. Network segmentation is the practice of splitting a computer network into isolated subnetworks, or network segments. This reduces the attack surface so that if a host on one network segment is compromised, the hosts on the other network segments are not affected. Many customers in regulated industries such as manufacturing, health care and life sciences, banking, and others implement network segmentation as part of their on-premises network security standards to reduce the impact of a breach and help address compliance requirements. Some AWS services also have network requirements that specify certain IP ranges to be used for endpoints, and may or may not support customers bringing their own IP pool (also called CoIP routing, see How to choose between CoIP and Direct VPC routing (DVR) modes on AWS Outposts rack for more information). Customers want the flexibility to use both routing modes (CoIP and DVR) on the same logical Outpost. With this new feature, AWS Outposts racks now support multiple LGW routing domains to meet subnetwork isolation and cloud service network requirements in an on-premises environment. For example, a leading automotive company deploys latency-sensitive manufacturing workloads on Outposts racks in a multi-AZ architecture for resiliency. This feature provides traffic separation between routing domains and enables both customer-owned IP (CoIP) and direct VPC routing (DVR) modes on the same logical Outpost.

In this post you will learn how to use multiple LGW routing domains on Outposts racks and considerations for implementation.

Overview

With the introduction of multiple LGW routing domains on Outposts, you can now create multiple routing domains and associate one or more VLANs with each routing domain. This allows you to integrate your Outposts rack into your existing on-premises network schema. Each LGW routing domain will have a unique LGW Virtual Interface (VIF) Group and an LGW Route Table, enabling logical network traffic isolation. You can have a mix of up to 10 active routing domains with route tables using either DVR or CoIP routing mode, and you can make changes to these routing domains as needed in a self-service fashion allowing for network flexibility as architectures are updated over time. These settings can be found in the AWS Outposts console under the Networking tab in the menu.

The following diagram shows an example of 3 VPCs, each with at least 1 subnet on the Outpost rack, and each VPC corresponds to its own routing domain. Each routing domain can then be associated with one or more VLANs, and one or more VPCs. A VPC can be associated with one or more LGW routing domain.

Architecture diagram showing 3 routing domains uplinking to an on-premises network.

Figure 1 – Architecture diagram showing 3 routing domains

Walkthrough

Before creating a LGW routing domain, first you’ll need to create an LGW VIF group and an LGW route table. A local gateway routing domain is the association of a local gateway route table and local gateway VIF group. Each VIF group can be associated with one or more VLANs, but a route table can only be associated with one VIF group.

To create a LGW VIF Group, navigate to the AWS Outposts console, go to LGW virtual interfaces groups, and select Create VIF group. Enter your VIF details which include BGP and VLAN routing information, you must create 4 LGW VIFs per VIF group.

Creating VIF group for RD1 routing domain

Figure 2 – Creating VIF group for RD1 routing domain

After creating your VIF group, create a LGW route table. You’ll have the option to use Direct VPC Routing (DVR) or Customer-owned IP address pool (CoIP) routing. If CoIP routing is selected, you’ll have the option to enter your CIDR before creating. A LGW route table’s routing mode cannot be changed after creating. However, you can disassociate a LGW route table from a VIF group and attach a new route table if you need to change the routing mode of a VIF group.

Figure 3 – Creating LGW route table for RD1 routing domain

After you’ve created your LGW route table and VIF group, you can proceed to the final step which is to create your LGW routing domain where you will associate the LGW route table and VIF group.

Create LGW routing domain form for RD1 example

Figure 4 – Creating LGW routing domain for RD1

You can view and create up to 10 active routing domains through the AWS Outposts console under the Networking tab.

Figure 5 – Local Gateway (LGW) routing domains

Considerations

  • Multiple LGW routing domains feature is only available on second-generation Outposts racks.
  • Avoid overlapping IP addresses across subnetworks and local routing domains as those can create IP routing conflicts.
  • A VIF group can only be associated to one LGW route table/routing domain at a time. A routing domain is the association of a VIF group and LGW route table.
  • LGW routing domain will allow for logical local network traffic isolation, however all traffic will still travel across your local gateway Link Aggregation Control Protocol (LACP) Link Aggregation Group (LAG) to uplink into your on-premises network.
  • Additional network isolation can be achieved through Virtual Routing and Forwarding (VRF) on Cisco platforms or Routing Instances on Juniper equipment, providing logical separation of routing tables and enabling secure multi-tenancy within the same physical infrastructure.
  • You can associate a VPC to one or more LGW routing domains. You can self-serve to change VPC association as needed. Multiple on-premises VLANs can be connected to a single routing domain.

Conclusion

This post demonstrated how to configure multiple local routing domains on Outposts racks to integrate into your on-premises network. For more information see LGW routing domains section in the AWS Outposts user guide. Reach out to your AWS account team to learn more about Outposts racks network configuration options.

In addition to multiple LGW routing domains, we have also announced several updates to Outposts in the past week to help you meet digital sovereignty and local data processing needs. To learn more, read the following announcements:

To discuss Outposts with an expert on any of these topics, submit this form.

Metasploit Wrap-Up 01/16/2025

Post Syndicated from Simon Janusz original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-01-16-2025

Persistence, dMSA Abuse & RCE Goodies

This week, we have received a lot of contributions from the community, such as h00die, Chocapikk and countless others, which is greatly appreciated. This week’s modules and improvements in Metasploit Framework range from new modules, such as dMSA Abuse (resulting in escalation of privilege in Windows Active Directory environments), authenticated and unauthenticated RCE modules, as well as many improvements and additions to the persistence modules and techniques.

New module content (13)

BadSuccessor: dMSA abuse to Escalate Privileges in Windows Active Directory

Authors: AngelBoy, Spencer McIntyre, and jheysel-r7

Type: Auxiliary

Pull request: #20472 contributed by jheysel-r7 

Path: admin/ldap/bad_successor

Description: This adds an exploit for “BadSuccessor” which is a vulnerability whereby a user with permissions to an Organizational Unit (OU) in Active Directory can create a Delegated Managed Service Account (dMSA) account in such a way that it can lead to the issuance of a Kerberos ticket for an arbitrary user.

Control Web Panel /admin/index.php Unauthenticated RCE

Authors: Egidio Romano and Lukas Johannes Möller

Type: Exploit

Pull request: #20806 contributed by JohannesLks 

Path: linux/http/control_web_panel_api_cmd_exec 

AttackerKB reference: CVE-2025-67888

Description: This adds a new module for Control Web Panel (CVE-2025-67888). The vulnerability is unauthenticated OS command injection through an exposed API. The modules require Softaculous to be installed.

Prison Management System 1.0 Authenticated RCE via Unrestricted File Upload

Author: Alexandru Ionut Raducu

Type: Exploit

Pull request: #20811 contributed by Xorriath 

Path: linux/http/prison_management_rce 

AttackerKB reference: CVE-2024-48594

Description: This adds a new module for Prison Management System 1.0 (CVE-2024-48594). The module requires admin credentials, which are subsequently used to exploit unrestricted file upload to upload a webshell.

udev Persistence

Author: Julien Voisin

Type: Exploit

Pull request: #20796 contributed by h00die 

Path: linux/persistence/udev

Description: This moves the udev persistence module into the persistence category and adds the persistence mixin.

n8n Workflow Expression Remote Code Execution

Author: Lukas Johannes Möller

Type: Exploit

Pull request: #20810 contributed by JohannesLks 

Path: multi/http/n8n_workflow_expression_rce

AttackerKB reference: CVE-2025-68613

Description: This adds a new module for n8n (CVE-2025-68613). The vulnerability is authenticated remote code execution in the workflow expression evaluation engine. The module requires credentials to create a malicious workflow that executes system commands via a JavaScript payload.

Web-Check Screenshot API Command Injection RCE

Author: Valentin Lobstein [email protected] 

Type: Exploit

Pull request: #20791 contributed by Chocapikk 

Path: multi/http/web_check_screenshot_rce 

AttackerKB reference: CVE-2025-32778

Description: Adds an exploit module for CVE-2025-32778, a command injection vulnerability in Web-Check’s screenshot API endpoint which allows unauthenticated remote code execution by injecting shell commands via URL query parameters in the /api/screenshot endpoint.

Accessibility Features (Sticky Keys) Persistence via Debugger Registry Key

Authors: OJ Reeves and h00die

Type: Exploit

Pull request: #20751 contributed by h00die 

Path: windows/persistence/accessibility_features_debugger

Description: This updates the Windows sticky keys post persistence module to use the new persistence mixin.

WMI Event Subscription Event Log Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_event_log

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

WMI Event Subscription Interval Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_interval

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

WMI Event Subscription Process Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_process

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

WMI Event Subscription Logon Timer Persistence

Authors: Nick Tyrer <@NickTyrer> and h00die

Type: Exploit

Pull request: #20706 contributed by h00die 

Path: windows/persistence/wmi/wmi_event_subscription_uptime

Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.

Linux Chmod

Author: bcoles [email protected] 

Type: Payload (Single)

Pull request: #20845 contributed by bcoles 

Path: linux/armle/chmod and linux/aarch64/chmod

Description: Adds Linux ARM 32-bit / 64-bit Little Endian chmod payloads.

Enhancements and features (7)

  • #20706 from h00die – Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.
  • #20751 from h00die – This updates the Windows sticky keys post persistence module to use the new persistence mixin.
  • #20785 from Chocapikk – This adds Waku framework support to the existing react2shell module. Waku is a minimal React framework which differs slightly compared to Node.js. The module maintains backward compatibility with existing Next.js targets while adding Waku support through a modular framework configuration system.
  • #20786 from zeroSteiner – This updates the module code to merge the target Arch and Platform entries into the module’s top level data. Prior to this change module developers had to define Arch and Platform entries twice, once at the module level and again per individual target. This updates over 500 modules and removes that duplication.
  • #20796 from h00die – This moves the udev persistence into the persistence category and adds the persistence mixin.
  • #20853 from zeroSteiner – Bumps metapsloit-payloads to 2.0.239.
  • #20855 from h00die – Adds additional ATT&CK references to persistence modules.

Bugs fixed (2)

  • #20738 from Shubham0699 – This fixes an issue in the bailiwicked DNS modules that was causing the module to fail with a stack trace due to a programming error.
  • #20847 from dwelch-r7 – This updates the auxiliary/scanner/ssh/ssh_login module to remove stale documentation, remove unnecessary characters that were printed in the output and update the correct documentation with the new information about key usage.

Documentation added (1)

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

[$] A free and open-source rootkit for Linux

Post Syndicated from daroc original https://lwn.net/Articles/1053099/

While there are several rootkits that target Linux, they have so far not fully
embraced the open-source ethos typical of Linux software.
Luckily, Matheus Alves has been working to remedy
this lack by creating

an open-source rootkit called Singularity
for Linux systems. Users who feel
their computers are too secure can install the Singularity kernel module in
order to allow remote code execution, disable security features, and hide files
and processes from normal administrative tools. Despite its many features,
Singularity is not currently known to be in use in the wild — instead, it
provides security researchers with a testbed to investigate new detection and
evasion techniques.

How to improve email sender reputation with Amazon SES Email Validation

Post Syndicated from Zip Zieper original https://aws.amazon.com/blogs/messaging-and-targeting/how-to-improve-email-sender-reputation-with-amazon-ses-email-validation/

If you’re sending emails at scale with Amazon Simple Email Service (Amazon SES), maintaining high deliverability depends on more than the content you send. It’s about who receives those emails. Mailbox providers like Gmail, Yahoo, and Outlook assign reputation scores based on your sending practices, domain and IP authentication records, message quality, and recipient engagement. These providers use their own algorithms to decide whether your emails reach the inbox, are filtered as spam, or aren’t delivered at all. For more information about managing your email reputation, see The Four Pillars of Managing Email Reputation. In this post, we show you how the Amazon SES Email Validation feature can help you to protect your sender reputation.

The email bounce rate is the percentage of emails that fail to deliver and is one of the most critical factors affecting your sender reputation. Every bounce damages your sender reputation. Mailbox providers like Gmail and Outlook closely monitor bounce rates, and accounts that bounce over 5% trigger warnings. If your account bounce rate exceeds 10%, the email services providers might throttle, or completely block sending. For customers sending email at scale with Amazon SES, a high bounce rate may trigger immediate consequences: damaged sender reputation, blocked deliverability, and ISP penalties that can throttle or suspend your entire email program. Traditional approaches to email quality are reactive, because you will only discover problems after bounces have damaged your reputation. While account suppression lists protect against known problematic addresses, they can’t protect you from the normal decay of email address quality that occurs because of job changes, abandoned mailboxes, domain expirations, or bots and bad actors looking to damage your email reputation.

Use Amazon SES Email Validation to help you protect your sender reputation

Amazon SES Email Validation shifts bounce management from reactive to proactive, helping you detect problems before they damage your sender reputation. The feature provides two validation approaches: the Email Validation API for timely checks during registration and Auto Validation to automatically review all outbound email addresses before sending and only deliver messages to recipients that meet your selected validation threshold. Both methods are intended to catch problem addresses before they become bounces, helping to protect your sender reputation.

In this post, we guide you through implementing both validation approaches using AnyCompany—a fictitious ecommerce website—as our example. You will see how AnyCompany might use the Email Validation API for timely registration checks on address acquisition and Auto Validation at time of sending. You’ll learn how to protect your sender reputation proactively and integrate validation into existing workflows with minimal disruption. We also show you how to use Amazon CloudWatch metrics to improve email list health over time. After you’re done reading and experimenting, you’ll understand how Amazon SES Email Validation can help transform your email operations from reactive bounce management to proactive quality assurance.

Solution overview – how to use the Email Validation API to avoid ingesting invalid email addresses

You can use the Email Validation API to validate email addresses through synchronous API calls to check addresses at the point of collection. This method gives you immediate feedback about address validity and helps prevent invalid addresses from entering your database. You control when validation occurs and how to handle the results. The Email Validation API costs $0.01 per validation using the API or the AWS Management Console for Amazon SES. See Amazon SES pricing for details.

The Amazon SES console uses the Email Validation API to manually validate up to 10 email addresses at a time. The results are shown in the console—shown in the following screenshot—and you can export the results to a CSV file.

The Email Validate API can be used in your code or using the AWS Command Line Interface (AWS CLI) to validate individual email addresses through synchronous API calls. This method is well-suited for validating addresses at the point of collection—during user registration, subscription form submission, or during an email list import to help prevent invalid addresses from entering your database. The following is an example using the AWS CLI.

aws sesv2 get-email-address-insights \
    --email-address [email protected] \
    --region us-east-1

The API returns a response structure similar to the following example:

{
  "MailboxValidation": {
    "IsValid": {
      "ConfidenceVerdict": "HIGH"
    },
    "Evaluations": {
      "HasValidSyntax": {
        "ConfidenceVerdict": "HIGH"
      },
      "HasValidDnsRecords": {
        "ConfidenceVerdict": "MEDIUM"
      },
      "MailboxExists": {
        "ConfidenceVerdict": "MEDIUM"
      },
      "IsRoleAddress": {
        "ConfidenceVerdict": "LOW"
      },
      "IsDisposable": {
        "ConfidenceVerdict": "LOW"
      },
      "IsRandomInput": {
        "ConfidenceVerdict": "LOW"
      }
    }
  }
}

Understanding Email Validation API verdicts

For each email, the Email Validation API returns an overall validity confidence with three possible aggregate verdicts:

  • HIGH – The email address passed all critical validation checks and is highly likely to be deliverable. These addresses can be accepted without additional scrutiny.
  • MEDIUM – The email address passed basic validation but has characteristics that might affect deliverability (such as being a role address or having uncertain mailbox existence). Your use case and bounce risk tolerance should be used to determine whether to accept these addresses.
  • LOW – The email address failed one or more critical validation checks and is unlikely to be deliverable. Your use case and bounce risk tolerance will most likely cause you to reject these addresses.

To reach the overall validity confidence, the Email Validation API performs six detailed checks on each email address:

  • Syntax validation (HasValidSyntax) – Confirms the address follows RFC 5321 and RFC 5322 standards for email address formatting. This catches obvious errors such as missing @ symbols or invalid characters.
  • DNS verification (HasValidDnsRecords) – Validates that the domain exists and has proper mail exchange (MX) records and corresponding A records configured. This helps confirm that the domain can receive email.
  • Mailbox existence (MailboxExists) – Predicts whether the specific mailbox exists and can receive messages.
  • Role address detection (IsRoleAddress) – Identifies generic addresses like [email protected] or [email protected] that typically represent shared mailboxes rather than individual recipients.
  • Disposable email detection (IsDisposable) – Checks temporary email services like mailinator.com or guerrillamail.com that users often employ to avoid providing real contact information.
  • Random input detection (IsRandomInput) – Checks randomly generated patterns.

For more information about response values and data types, see the MailboxValidation data type in the Amazon SES API v2 reference.

The Email Validation API provides a dashboard in the Amazon SES console that you can use to view email address verification results over time, with the ability to look back for up to one month, as shown in the following screenshot.

Use auto validation to help prevent bounces when sending from Amazon SES

Amazon SES Auto Validation automatically performs comprehensive address validation through multiple checks such as syntax validation, DNS records, and others before each message is sent. When auto validation is enabled, Amazon SES will only deliver messages to recipients that meet your selected validation threshold. This helps you protect your sender reputation by preventing sends to addresses that have a high probability of being invalid or risky without requiring manual intervention or API integration. Auto Validation must be enabled separately for each AWS region in your account. For example, if you enable it in us-east-1, it will not be active in us-west-2 unless you explicitly enable it there as well. You can enable it at the account level for an entire region, or selectively within configuration sets. Auto validation costs $0.01 per 1,000 validations. Be aware that sends suppressed by Auto Validation count towards your daily send quota, and you will be charged the standard outgoing message fee for suppressed sends (in addition to the fee for auto validation). See Amazon SES pricing for more information.

When enabled at the AWS account level, you set the Validation threshold to determine which email addresses to suppress based on their validity confidence, as shown in the following screenshot.

  • Amazon SES managed threshold (recommended) – Amazon SES automatically manages the threshold to suppress invalid addresses based on your sending patterns and reputation. This option allows Amazon SES to optimize the validation threshold dynamically. Use this threshold when you want AWS to handle validation decisions based on your account’s specific characteristics.
  • Custom threshold –
    • High – Delivers emails only to addresses with high delivery likelihood. This provides maximum protection for your sender reputation but might suppress some legitimate addresses with medium delivery confidence. Use this threshold for critical transactional emails or when protecting sender reputation is your top priority.
    • Medium – Delivers emails to addresses with medium or high delivery likelihood. This balances reputation protection with delivery reach by allowing addresses with moderate deliverability scores. Use this threshold for marketing campaigns where you want to maximize reach while still filtering obviously invalid addresses.

You will usually find that using the recommended Amazon SES managed threshold works best for the bulk of your sending, however for certain use cases you might want to override the account setting and use a custom threshold in your configuration set. If you choose High or Medium thresholds instead of Amazon SES managed (as shown in the following screenshot), it’s important that you monitor your delivery metrics and validation results regularly.

Auto Validation applies to all outbound emails sent through your account. Addresses that don’t meet your threshold will be suppressed with the bounceSubType of EmailValidationSuppressed. Suppressed sends count towards your daily send quota, and you will be charged the standard outgoing message fee for suppressed sends in addition to the fee for auto validation.

{
  "Type": "Notification",
  "MessageId": "0ded6fd6-4e59-5ae0-9782-0e68faa886e7",
  "TopicArn": "arn:aws:sns:us-east-1:252640393490:ses-auto-validate",
  "Subject": "Amazon SES Email Event Notification",
  "Message": "{\"**eventType**\":\"**Bounce**\",\"bounce\":{\"feedbackId\":\"0100019b345a05a0-95e3062a-9594-499f-aafc-dc2dc9647cb6-000000\",\"**bounceType**\":\"**Permanent**\",\"**bounceSubType**\":\"**EmailValidationSuppressed**\",\"bouncedRecipients\":"
}

How AnyCompany might use the Email Validation API and auto validation

AnyCompany runs an ecommerce platform for both business and consumer office supplies. The company’s website hosts various web-forms for customers to create accounts and sign up to receive newsletters and discount offers. When they place orders through the platform, AnyCompany’s system sends order confirmations and delivery tracking emails. Today, when a new user registers through one of the web forms, AnyCompany sends a verification email to confirm the user’s email address, contact details, and opt-in to the company’s emails. If a user misspells their email address, they will never receive this verification email. Frustrated, they might move on to another provider. Similarly, if a bot or bad actor deliberately submits invalid addresses to the web form, verification emails will bounce. Both scenarios cost AnyCompany money with no return; at scale, a high bounce rate might cause email service providers to throttle or block future sends. AnyCompany previously investigated various third-party email validation services, but the engineering work, security reviews, and costs outweighed the expected benefits. This necessitated the cloud team’s constant and careful vigilance over the company’s bounce rate and reputation, diverting resources that the company would prefer to deploy elsewhere. As an ecommerce company, AnyCompany needs to be highly protective of its sender reputation. With email validation now built directly into Amazon SES, AnyCompany can bypass the complexity and cost of third-party tools and directly benefit from proactive bounce prevention across all email use cases. In the following section, we guide you through the simple steps AnyCompany might take to implement Amazon SES Email Validation.

Prerequisites

Before implementing Email Validation, you’ll need:

AWS account :

  • An AWS account with Amazon SES enabled in your desired AWS Region
  • AWS CLI version 2.0 or later installed and configured

Required IAM permissions:

Your IAM user or role needs the following permissions to configure Email Validation:

  • ses:PutAccountSuppressionAttributes – To enable and configure Email Validation at the account level
  • ses:GetAccount to verify Email Validation configuration
  • ses:CreateConfigurationSet when creating a new configuration set
  • ses:PutConfigurationSetSuppressionOptionsto override validation settings for specific configuration sets
  • ses:GetEmailAddressInsights to call the Email Validation API
  • iam:CreateServiceLinkedRole  creates an IAM service-linked role that is used by Amazon SES to publish CloudWatch metrics
  • cloudwatch:GetMetricStatistics – To retrieve validation metrics

Development environment:

  • Familiarity with AWS CLI commands and JSON configuration files
  • For API integration, SDK support for Amazon SES API v2 in your preferred programming language
  • Access to your application’s user registration code

Existing Amazon SES configuration:

  • At least one verified email address or domain in Amazon SES

While the Email Validation API works with an AWS account that is in the Amazon SES sandbox, auto validation is best demonstrated after your AWS account has been granted production access.

  • (Optional) Configuration sets created for different email types (transactional, marketing, and so on)

Validating email addresses at acquisition with the Email Validation API

To prevent bad addresses from entering their customer database at time of acquisition, AnyCompany will integrate the Email Validation API directly into their registration form. When a user submits their contact details, including email address, the Email Validation API is used. Results arrive within 100 milliseconds, with the overall validity confidence and six detailed checks of the email address. AnyCompany will then use the results and custom business logic they designed for their different use cases. For example, for their B2B business, they might allow registrations with high overall confidences and a role address, such as [email protected]. For the consumer business, they might accept registrations with medium overall confidences, but always reject emails that the API identifies as disposable, such as [email protected] or random, such as [email protected].

Sample code snippets

The code snippets in this section are examples only and are not intended for production use.

Step 1: Validate email address on form submission

When a user submits the registration form, AnyCompany’s application calls the Email Validation API before creating the account:

import boto3

ses_client = boto3.client('sesv2', region_name='us-east-1')

def validate_registration_email(email_address):
    try:
        response = ses_client.get_email_address_insights(
            EmailAddress=email_address
        )
        return response
    except Exception as e:
        # Handle API errors gracefully
        print(f"Validation error: {e}")
        return None

Step 2: Apply business rules based on verdict

AnyCompany’s business logic handles different validation outcomes:

def should_accept_email(validation_response, registration_type):
    if not validation_response:
        # API error - accept email but flag for manual review
        return True, "accepted_with_warning"

    overall_verdict = validation_response['MailboxValidation']['IsValid']['ConfidenceVerdict']
    checks = validation_response['MailboxValidation']['Evaluations']

    # Always reject FAIL verdicts
    if overall_verdict == 'LOW':
        return False, "rejected_invalid"

    # Always accept PASS verdicts
    if overall_verdict == 'HIGH':
        return True, "accepted"

    # Handle NEUTRAL verdicts based on registration type
    if overall_verdict == 'MEDIUM':
        # Reject disposable emails for all registration types
        if checks['IsDisposable']['ConfidenceVerdict'] == 'HIGH':
            return False, "rejected_disposable"

        # Accept role addresses for B2B, reject for consumer
        if checks['IsRoleAddress']['ConfidenceVerdict'] == 'HIGH':
            if registration_type == 'b2b':
                return True, "accepted_role_address"
            else:
                return False, "rejected_role_address"

        # Accept other NEUTRAL cases with warning
        return True, "accepted_with_warning"

Step 3: Provide user-friendly error messages

When validation fails, AnyCompany provides specific, actionable feedback (you can add more conditions based on your requirements):

def get_user_error_message(validation_response):
    checks = validation_response['Evaluations']

    if checks['HasValidSyntax']['ConfidenceVerdict'] == 'LOW':
        return "Please check your email address for typos. It appears to have formatting errors."

    if checks['HasValidDnsRecords']['ConfidenceVerdict'] == 'LOW':
        return "The domain in your email address doesn't appear to exist. Please verify you entered it correctly."

    if checks['IsDisposable']['ConfidenceVerdict'] == 'HIGH':
        return "Temporary email addresses are not accepted. Please use a different email address."

    if checks['IsRoleAddress']['ConfidenceVerdict'] == 'HIGH':
        return "Please use a personal email address rather than a shared mailbox like support@ or admin@."

    return "We couldn't verify this email address. Please check for typos and try again."

Step 4: Suggest corrections for common mistakes

For addresses that fail DNS validation, AnyCompany suggests common corrections to popular domain typos.

def suggest_email_correction(email_address):
    common_domains = {
        'gmial.com': 'gmail.com',
        'gmai.com': 'gmail.com',
        'yahooo.com': 'yahoo.com',
        'hotmial.com': 'hotmail.com',
        'outlok.com': 'outlook.com'
    }

    # Extract domain from email
    if '@' in email_address:
        local, domain = email_address.split('@', 1)

        # Check for common misspellings
        if domain.lower() in common_domains:
            suggested_domain = common_domains[domain.lower()]
            return f"{local}@{suggested_domain}"

    return None

Key benefits of the Email Validation API

The Email Validation API provide proactive quality control by preventing invalid addresses from entering AnyCompany’s database, preventing the reputation damage that occurs when they send to addresses that bounce.

  • Immediate user feedback – Because validation results return within milliseconds, AnyCompany can provide real-time feedback during registration without impacting user experience.
  • Flexible policy enforcement – AnyCompany can use individual check results to define custom validation policies that match their various business requirements, accepting or rejecting addresses based on use case-specific risk tolerance.
  • Cost-effective validation – AnyCompany pays only for the addresses they validate, with no infrastructure to provision or manage and no license fees. Preventing a single bounce might save more than the cost of validation.

By integrating the Email Validation API into their registration workflow, AnyCompany can transform their approach from reactive bounce management to proactive quality assurance. Invalid addresses are prevented from entering their database, legitimate customers receive verification emails reliably, and their sender reputation remains protected with little to no ongoing effort.

Set up a CloudWatch alarm for high rates of LOW verdicts

You can configure CloudWatch alarms to notify you when validation patterns indicate a consistently high rate of LOW verdicts. This might indicate malicious bots attempting to sign up through a web-form or other mechanism.

The following example creates a CloudWatch alarm that fires when the rate of LOW verdicts exceeds 20%.

aws cloudwatch put-metric-alarm \
  --region us-east-1 \
  --alarm-name "EmailInsights-LOW-Rate-Above-20-Percent" \
  --alarm-description "Alarm when LOW confidence verdict rate exceeds 20%" \
  --comparison-operator GreaterThanThreshold \
  --threshold 20 \
  --evaluation-periods 2 \
  --treat-missing-data notBreaching \
  --metrics '[
    {
      "Id": "low",
      "MetricStat": {
        "Metric": {
          "MetricName": "EmailAddressInsights.ConfidenceVerdict.LOW",
          "Namespace": "AWS/SES"
        },
        "Period": 300,
        "Stat": "Sum"
      },
      "ReturnData": false
    },
    {
      "Id": "medium",
      "MetricStat": {
        "Metric": {
          "MetricName": "EmailAddressInsights.ConfidenceVerdict.MEDIUM",
          "Namespace": "AWS/SES"
        },
        "Period": 300,
        "Stat": "Sum"
      },
      "ReturnData": false
    },
    {
      "Id": "high",
      "MetricStat": {
        "Metric": {
          "MetricName": "EmailAddressInsights.ConfidenceVerdict.HIGH",
          "Namespace": "AWS/SES"
        },
        "Period": 300,
        "Stat": "Sum"
      },
      "ReturnData": false
    },
    {
      "Id": "e1",
      "Expression": "IF((low+medium+high)>0, low/(low+medium+high)*100, 0)",
      "Label": "LOW Rate Percentage",
      "ReturnData": true
    }
  ]'

How AnyCompany uses validation metrics

AnyCompany monitors their Email Validation dashboard in the Amazon SES console to track list quality trends. For example, if they notice an increase in disposable email failures, they can add additional client-side validation to their registration forms to discourage this behavior. When Auto Validation blocks a spike of invalid addresses from a specific partner marketing campaign, they avoid the problems associated with a spike in bounces while being better informed when investigating the list source and removing or cleaning it for future campaigns.

Validating email addresses at send time with Auto Validation

AnyCompany has been operating its online platform for many years without a way to validate email addresses. The company also makes frequent acquisitions and partnerships that regularly introduce new email addresses into their sending. This means that no matter how well the new registration for with the Email Validation API performs, they will always have some invalid email addresses in their outbound sends.

This is one of the scenarios that can be addressed with no code or process changes by using Auto Validation. When enabled at the AWS account level, Auto Validation checks each address before sending, automatically suppressing the send of invalid addresses, adding those addresses to the account suppression list, and generating bounce notification events. These bounce events appear in Amazon SES event publishing and can be monitored using Amazon CloudWatch, Amazon Simple Notification Service (Amazon SNS), or Amazon EventBridge or written to an Amazon Simple Storage Service (Amazon S3) bucket. Auto Validation bounce events appear as:

  • Bounce type: Permanent for addresses that will never be deliverable
  • Bounce subtype: EmailValidationSuppressed indicating Auto Validation blocked the send

Because it’s implemented in Amazon SES events, AnyCompany can handle address validation failures the same way they currently handle actual bounces from mailbox providers, maintaining consistency in their email processing workflows.

Conclusion

Amazon SES Email Validation addresses critical needs for organizations sending email at scale: preventing invalid addresses at registration and automatically filtering risky recipients before sending. The feature’s two complementary approaches—the Email Validation API for real-time checks and Auto Validation for automatic send-time filtering—give you flexibility to implement validation where it makes the most sense for your workflows.

Use the Email Validation API to:

  • Validate at point of collection (registration, imports)
  • Receive immediate user feedback
  • Build custom validation workflows
  • Validate before database entry
  • Validate up to 10 addresses

Use Auto Validation to:

  • Automatically protect ongoing campaigns automatically
  • Avoid code changes to sending logic
  • Provide consistent quality across all sends
  • Set organization-wide quality standards

By implementing both features of Amazon SES Email Validation, you can better protect your sender reputation by proactively preventing bounces, reducing the possibility of high bounce rates that can damage your deliverability.

Next steps

Start improving your email deliverability today:

  1. Enable Email Validation in your AWS account using the Amazon SES console or the AWS CLI
  2. Implement API validation at your registration points to improve data quality from the start
  3. Configure Auto Validation policies to protect your sender reputation across all campaigns
  4. Set up CloudWatch dashboards to track validation performance and identify list quality trends
  5. Review validation metrics weekly to refine your validation policies based on actual patterns

For more information about Amazon SES Email Validation, see the Amazon SES Developer Guide.


About the authors

AI and the Corporate Capture of Knowledge

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/01/ai-and-the-corporate-capture-of-knowledge.html

More than a decade after Aaron Swartz’s death, the United States is still living inside the contradiction that destroyed him.

Swartz believed that knowledge, especially publicly funded knowledge, should be freely accessible. Acting on that, he downloaded thousands of academic articles from the JSTOR archive with the intention of making them publicly available. For this, the federal government charged him with a felony and threatened decades in prison. After two years of prosecutorial pressure, Swartz died by suicide on Jan. 11, 2013.

The still-unresolved questions raised by his case have resurfaced in today’s debates over artificial intelligence, copyright and the ultimate control of knowledge.

At the time of Swartz’s prosecution, vast amounts of research were funded by taxpayers, conducted at public institutions and intended to advance public understanding. But access to that research was, and still is, locked behind expensive paywalls. People are unable to read work they helped fund without paying private journals and research websites.

Swartz considered this hoarding of knowledge to be neither accidental nor inevitable. It was the result of legal, economic and political choices. His actions challenged those choices directly. And for that, the government treated him as a criminal.

Today’s AI arms race involves a far more expansive, profit-driven form of information appropriation. The tech giants ingest vast amounts of copyrighted material: books, journalism, academic papers, art, music and personal writing. This data is scraped at industrial scale, often without consent, compensation or transparency, and then used to train large AI models.

AI companies then sell their proprietary systems, built on public and private knowledge, back to the people who funded it. But this time, the government’s response has been markedly different. There are no criminal prosecutions, no threats of decades-long prison sentences. Lawsuits proceed slowly, enforcement remains uncertain and policymakers signal caution, given AI’s perceived economic and strategic importance. Copyright infringement is reframed as an unfortunate but necessary step toward “innovation.”

Recent developments underscore this imbalance. In 2025, Anthropic reached a settlement with publishers over allegations that its AI systems were trained on copyrighted books without authorization. The agreement reportedly valued infringement at roughly $3,000 per book across an estimated 500,000 works, coming at a cost of over $1.5 billion. Plagiarism disputes between artists and accused infringers routinely settle for hundreds of thousands, or even millions, of dollars when prominent works are involved. Scholars estimate Anthropic avoided over $1 trillion in liability costs. For well-capitalized AI firms, such settlements are likely being factored as a predictable cost of doing business.

As AI becomes a larger part of America’s economy, one can see the writing on the wall. Judges will twist themselves into knots to justify an innovative technology premised on literally stealing the works of artists, poets, musicians, all of academia and the internet, and vast expanses of literature. But if Swartz’s actions were criminal, it is worth asking: What standard are we now applying to AI companies?

The question is not simply whether copyright law applies to AI. It is why the law appears to operate so differently depending on who is doing the extracting and for what purpose.

The stakes extend beyond copyright law or past injustices. They concern who controls the infrastructure of knowledge going forward and what that control means for democratic participation, accountability and public trust.

Systems trained on vast bodies of publicly funded research are increasingly becoming the primary way people learn about science, law, medicine and public policy. As search, synthesis and explanation are mediated through AI models, control over training data and infrastructure translates into control over what questions can be asked, what answers are surfaced, and whose expertise is treated as authoritative. If public knowledge is absorbed into proprietary systems that the public cannot inspect, audit or meaningfully challenge, then access to information is no longer governed by democratic norms but by corporate priorities.

Like the early internet, AI is often described as a democratizing force. But also like the internet, AI’s current trajectory suggests something closer to consolidation. Control over data, models and computational infrastructure is concentrated in the hands of a small number of powerful tech companies. They will decide who gets access to knowledge, under what conditions and at what price.

Swartz’s fight was not simply about access, but about whether knowledge should be governed by openness or corporate capture, and who that knowledge is ultimately for. He understood that access to knowledge is a prerequisite for democracy. A society cannot meaningfully debate policy, science or justice if information is locked away behind paywalls or controlled by proprietary algorithms. If we allow AI companies to profit from mass appropriation while claiming immunity, we are choosing a future in which access to knowledge is governed by corporate power rather than democratic values.

How we treat knowledge—who may access it, who may profit from it and who is punished for sharing it—has become a test of our democratic commitments. We should be honest about what those choices say about us.

This essay was written with J. B. Branch, and originally appeared in the San Francisco Chronicle.

Security updates for Friday

Post Syndicated from jzb original https://lwn.net/Articles/1054683/

Security updates have been issued by AlmaLinux (gnupg2), Debian (firefox-esr), Oracle (cups, gnupg2, libpq, net-snmp, postgresql, postgresql:15, postgresql:16, transfig, and vsftpd), Red Hat (firefox), SUSE (apache2, curl, firefox, gpg2, hawk2, libcryptopp-devel, openCryptoki, python310, python311-urllib3, rke2, squid, and tomcat), and Ubuntu (cpp-httplib, git, python-apt, and simgear).

Astro is joining Cloudflare

Post Syndicated from Fred Schott original https://blog.cloudflare.com/astro-joins-cloudflare/

The Astro Technology Company, creators of the Astro web framework, is joining Cloudflare.

Astro is the web framework for building fast, content-driven websites. Over the past few years, we’ve seen an incredibly diverse range of developers and companies use Astro to build for the web. This ranges from established brands like Porsche and IKEA, to fast-growing AI companies like Opencode and OpenAI. Platforms that are built on Cloudflare, like Webflow Cloud and Wix Vibe, have chosen Astro to power the websites their customers build and deploy to their own platforms. At Cloudflare, we use Astro, too — for our developer docs, website, landing pages, and more. Astro is used almost everywhere there is content on the Internet.

By joining forces with the Astro team, we are doubling down on making Astro the best framework for content-driven websites for many years to come. The best version of Astro — Astro 6 —  is just around the corner, bringing a redesigned development server powered by Vite. The first public beta release of Astro 6 is now available, with GA coming in the weeks ahead.

We are excited to share this news and even more thrilled for what it means for developers building with Astro. If you haven’t yet tried Astro — give it a spin and run npm create astro@latest.

What this means for Astro

Astro will remain open source, MIT-licensed, and open to contributions, with a public roadmap and open governance. All full-time employees of The Astro Technology Company are now employees of Cloudflare, and will continue to work on Astro. We’re committed to Astro’s long-term success and eager to keep building.

Astro wouldn’t be what it is today without an incredibly strong community of open-source contributors. Cloudflare is also committed to continuing to support open-source contributions, via the Astro Ecosystem Fund, alongside industry partners including Webflow, Netlify, Wix, Sentry, Stainless and many more.

From day one, Astro has been a bet on the web and portability: Astro is built to run anywhere, across clouds and platforms. Nothing changes about that. You can deploy Astro to any platform or cloud, and we’re committed to supporting Astro developers everywhere.

There are many web frameworks out there — so why are developers choosing Astro?

Astro has been growing rapidly:


Why? Many web frameworks have come and gone trying to be everything to everyone, aiming to serve the needs of both content-driven websites and web applications.

The key to Astro’s success: Instead of trying to serve every use case, Astro has stayed focused on five design principles. Astro is…

  • Content-driven: Astro was designed to showcase your content.

  • Server-first: Websites run faster when they render HTML on the server.

  • Fast by default: It should be impossible to build a slow website in Astro.

  • Easy to use: You don’t need to be an expert to build something with Astro.

  • Developer-focused: You should have the resources you need to be successful.

Astro’s Islands Architecture is a core part of what makes all of this possible. The majority of each page can be fast, static HTML — fast and simple to build by default, oriented around rendering content. And when you need it, you can render a specific part of a page as a client island, using any client UI framework. You can even mix and match multiple frameworks on the same page, whether that’s React.js, Vue, Svelte, Solid, or anything else:


Bringing back the joy in building websites

The more Astro and Cloudflare started talking, the clearer it became how much we have in common. Cloudflare’s mission is to help build a better Internet — and part of that is to help build a faster Internet. Almost all of us grew up building websites, and we want a world where people have fun building things on the Internet, where anyone can publish to a site that is truly their own.

When Astro first launched in 2021, it had become painful to build great websites — it felt like a fight with build tools and frameworks. It sounds strange to say it, with the coding agents and powerful LLMs of 2026, but in 2021 it was very hard to build an excellent and fast website without being a domain expert in JavaScript build tooling. So much has gotten better, both because of Astro and in the broader frontend ecosystem, that we take this almost for granted today.

The Astro project has spent the past five years working to simplify web development. So as LLMs, then vibe coding, and now true coding agents have come along and made it possible for truly anyone to build — Astro provided a foundation that was simple and fast by default. We’ve all seen how much better and faster agents get when building off the right foundation, in a well-structured codebase. More and more, we’ve seen both builders and platforms choose Astro as that foundation.

We’ve seen this most clearly through the platforms that both Cloudflare and Astro serve, that extend Cloudflare to their own customers in creative ways using Cloudflare for Platforms, and have chosen Astro as the framework that their customers build on. 

When you deploy to Webflow Cloud, your Astro site just works and is deployed across Cloudflare’s network. When you start a new project with Wix Vibe, behind the scenes you’re creating an Astro site, running on Cloudflare. And when you generate a developer docs site using Stainless, that generates an Astro project, running on Cloudflare, powered by Starlight — a framework built on Astro.

Each of these platforms is built for a different audience. But what they have in common — beyond their use of Cloudflare and Astro — is they make it fun to create and publish content to the Internet. In a world where everyone can be both a builder and content creator, we think there are still so many more platforms to build and people to reach.

Astro 6 — new local dev server, powered by Vite

Astro 6 is coming, and the first open beta release is now available. To be one of the first to try it out, run:

npm create astro@latest -- --ref next

Or to upgrade your existing Astro app, run:

npx @astrojs/upgrade beta

Astro 6 brings a brand new development server, built on the Vite Environments API, that runs your code locally using the same runtime that you deploy to. This means that when you run astro dev with the Cloudflare Vite plugin, your code runs in workerd, the open-source Cloudflare Workers runtime, and can use Durable Objects, D1, KV, Agents and more. This isn’t just a Cloudflare feature: Any JavaScript runtime with a plugin that uses the Vite Environments API can benefit from this new support, and ensure local dev runs in the same environment, with the same runtime APIs as production.


Live Content Collections in Astro are also stable in Astro 6 and out of beta. These content collections let you update data in real time, without requiring a rebuild of your site. This makes it easy to bring in content that changes often, such as the current inventory in a storefront, while still benefitting from the built-in validation and caching that come with Astro’s existing support for content collections.

There’s more to Astro 6, including Astro’s most upvoted feature request — first-class support for Content Security Policy (CSP) — as well as simpler APIs, an upgrade to Zod 4, and more.

Doubling down on Astro

We’re thrilled to welcome the Astro team to Cloudflare. We’re excited to keep building, keep shipping, and keep making Astro the best way to build content-driven sites. We’re already thinking about what comes next beyond V6, and we’d love to hear from you.

To keep up with the latest, follow the Astro blog and join the Astro Discord. Tell us what you’re building!

На второ четене: „Речник на войната“

Post Syndicated from Стефан Иванов original https://www.toest.bg/na-vtoro-chetene-rechnik-na-voynata-ot-ostap-slivinski/

„Речник на войната“ от Остап Сливински

На второ четене: „Речник на войната“

превод от украински Райна Камберова, Пловдив: изд. „Жанет 45“, 2024

Още малко остава до четиригодишнината от началото на войната на Русия в Украйна. Това прави тази книга още по-болезнена и важна. Тя флиртува опасно с автопародията на своята форма. Представете си речник, една от най-авторитарните текстови конструкции, наследник на просвещенската мания за категоризация, който внезапно признава собствената си импотентност. Ако Дидро и Д’Аламбер вярваха, че светът може да бъде картографиран и овладян чрез азбучен ред, то Сливински използва същата азбука, за да покаже как войната превръща всеки опит за ред в гротеска. Това не е деконструкция на жанра. Това е използване на скелета на Просвещението, за да се покаже разложението му.

Паралелите тук са множество и заплетени. На ум ни идва „Хазарски речник“ на Павич, но без магическия реализъм и със значително повече кръв. Припомняме си и Амброуз Биърс с неговия „Речник на дявола“, но докато при Биърс цинизмът е естетически избор, при Сливински той е физиологична необходимост. По-близо е дори до Бартовите „Митологии“, но с тази разлика, че тук демистификацията не е интелектуален жест, а екзистенциален императив.

Войната не ти позволява лукса на теоретизирането. Тя иска свидетелство, а не анализ.

Интересното е, че Сливински прави нещо още по-радикално от Милош или от късния Целан с неговата разпадната реч. Той не се опитва да върне думите към тяхната т.нар. „истинска“ етимологична чистота, нито да създаде нов травматичен език. Вместо това авторът показва как обикновеният език, с който пазаруваме, ругаем се едни други и флиртуваме, се деформира под натиска на историята. Балсамът остава балсам, но вече е и нещо друго. Той се превръща в обещание за цивилизация, носталгия по нормалността, почти метафизичен конструкт. Това е странно близко до феноменологията на Хайдегер, но изчистена от философския патос и пренесена в контекста на пазара на дребно в обсадения Мариупол.

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

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

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

На второ четене: „Речник на войната“

Едно от най-силните постижения на книгата е начинът, по който предметният свят придобива почти теологична тежест. Банята, лампата, тиксото, ключовете вече не са реквизит на войната, а последните острови на смисъла в океан от хаос. Тук Сливински е удивително близо до хайдегеровското разбиране за das Zeug, онова подръчно битие на предметите, което става видимо едва когато се счупи техният инструментален статус. Както става и при Дон ДеЛило, когато супермаркетът, колата или боклукът са пространства на дълбинна тревога.

Но за разлика от ДеЛило, при когото капитализмът произвежда излишък от значения и всичко е знак, всичко е симулакрум, при Сливински имаме обратната ситуация, защото предметите внезапно престават да бъдат излишни. Топлата вода не е удобство, тя става чудо. Тиксото върху прозореца не е временна мярка, то се превръща в новата коледна звезда и в символ на въображаемата сигурност. Това е свят, в който IKEA естетиката на заменимостта се сблъсква с бруталната житейска необходимост. Всеки предмет може да бъде последният, затова всеки предмет внезапно става свещен.

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

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

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

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

Паралелът не е директен, но е възможен. Сливински показва свят, в който избор вече няма. В България изборът все още съществува, но все по-често изглежда илюзорен. Можем да откажем да избираме между партии, които ни лъжат.

Можем да не сме потребители на медии, които ни манипулират. Можем да изберем да вярваме в бъдеще, което може и да не дойде. Това не е травма в украинския смисъл, но е хронична анемия на смисъла.

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

Има и втори пласт на сравнението. България често се мисли като преддверие на Европа, на модерността и на катастрофата. Винаги сме „на път да“, „на ръба на“, „пред възможността за“. Тази позиция произвежда специфична среда на отлагането и на симулацията. Речникът показва свят, в който репетициите са свършили. Войната не е възможна, нито е заплаха, тя е започнала. И четейки това, можем да си зададем неудобния въпрос какво от нашето „нормално“ всъщност е само репетиция? Какво би оцеляло, ако утре трябваше да бъде истинско?

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

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

езикът е последното бойно поле.

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

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


Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. За нея медията „Тоест“ е отличена с Националната награда „Христо Г. Данов“ (2025) за принос в представянето на българската книга.

Рубриката е част от партньорската програма Читателски клуб „Тоест“, благодарение на която активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на включените издателства. Изборът на заглавия обаче е единствено на авторите Стефан Иванов, Севда Семер и Антония Апостолова, които биха ви препоръчали тези книги и ако имаше как да се разходите с тях в книжарницата. 

В броячите е силата. Не, в гражданите

Post Syndicated from Емилия Милчева original https://www.toest.bg/v-broyachite-e-silata-ne-v-grazhdanite/

Бюлетините не определят резултатите от изборите. Преброителите определят резултата. 

В броячите е силата. Не, в гражданите

Тази фраза принадлежи на американския политик Уилям Туид – Боса, известен и като Бос Туид, шефа на „политическата машина“ „Тамани Хол“. 

Католическата организация на практика управлява Демократическата партия в Ню Йорк и контролира изборите по времето на Позлатената епоха, но също така прибира милиони долари чрез измами, подкупи и контрол над обществени поръчки. С част от тези средства подкупва и съдии за решения в своя полза. Големи обществени проекти, като болници и пътища, пищни музеи, съдилища, дори Бруклинския мост, са с доста завишени разходи, а разликата отива при Туид и неговите приближени. Например тогавашната Съдебна палата, първоначално планирана за 250 000 долара, струва над 13 млн. долара, без да е завършена, и цялата разлика е усвоена от обръчите на Туид, т.нар. Τweed Ring.

Заради корупцията, машинациите и манипулациите на избори карикатуристи рисуват Туид, опрян на урна, на която пише: 

Ιn Counting There Is Strength („В броенето е силата“). 

Впрочем именно благодарение на вестник The New York Times и на карикатурите на Томас Наст в Harper’s Weekly корупцията на Туид е извадена на показ. Той е обвинен в над 200 престъпления, осъден да лежи 12 години и умира в затвора през 1878 г. „Тамани Хол“ се превръща в нарицателно за политическа корупция.

В броячите е силата. Не, в гражданите
Източник: Wikimedia

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

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

Усърдно помагат и преброителите. А точно те са първата бариера срещу властта на клептократите. Как ще се гласува – с хартиени бюлетини или с машини, е второстепенно, ако хората, които броят гласовете, не са независими, почтени и добре обучени. 

Готовността да се следват правилата осигурява реална легитимност на изборите. 

Дори перфектно разработени технологии не могат да компенсират липсата на етични и компетентни хора в секционните избирателни комисии.

Преброители на къса каишка

В България в ΧΧΙ век изборните бюлетини броят същите хора, които и „Тамани Хол“ е използвала в средата на ΧΙΧ век: партийни активисти; хора на местния „бос“; служители, зависими от партийна благословия (работа, услуги, закрила). И онези „броячи“ отпреди повече от 150 години, и днешните си служат с едни и същи методи: някои бюлетини лесно стават невалидни чрез драсване, неправилно прегъване, зацапване, скъсване на ъгълче и пр.; а други се дописват или направо подменят с предварително попълнени. 

Машинното гласуване не е панацея, но успя значително да намали поне невалидните бюлетини, които през 2017 г. например бяха неприлично много – 169 009, до под 10 000 на вота през 2022 г. Изплашени, партиите от статуквото – ГЕРБ, БСП и ДПС, решиха отново да върнат хартията в играта, свеждайки машините до принтери.

Няма по-голямо доказателство колко много залагат на изборни манипулации от упорството, с което се впускат да променят правилата за гласуване почти преди всеки вот. Машините нарушиха спокойствието на партийния апарат, но не елиминираха заплахата от купен и контролиран вот. А и не биха могли – това е работа на МВР.

При машинното гласуване обаче „броячите“ са безполезни, машините автоматично представят резултатите и контролните разписки. Дочоолу, Гочоолу и останалите аватари на Бос Туид не могат да разпределят най-ценното нещо в една демокрация – гласовете на избирателите, като че са зарзават за консерви. 

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

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

Диктатурата на „Д“

Колкото по-безобразни са промените, които ГЕРБ–СДС и ДПС – Ново начало подготвят в Изборния кодекс, толкова по-голям е страхът им от срив на предстоящите напролет предсрочни избори. Замисълът, който стана явен тези дни, го потвърждава. Предложените оптични скенери от „хартиената коалиция“ – ГЕРБ, БСП, „Има такъв народ“ и ДПС – Ново начало, захранвани (и) с манипулиран вот, зачеркват машините, защото те им пречат. 

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

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

Помним как на предишните избори в град Белица членка на секционната избирателна комисия гласува вместо избирателите. Пред всички тя попълва празни бюлетини и ги разпределя за две политически сили – ГЕРБ–СДС и ДПС – Ново начало. От 2015 г. община Белица се управлява от най-любимия и верен кмет на олигарха Пеевски – Радослав Ревански. 

Нали никой не си представя, че администрацията на община, управлявана от една политическа сила, няма да нагласи гласове в нейна полза? Всъщност най-големият позор е, че наистина никой не си го представя…

Конституционният съд (КС) обаче намери достатъчно основания да отмени избора на 16 депутати в 51-вия парламент заради сигналите за честността на вота и в резултат на това в Народното събрание влезе и деветата политическа сила – „Величие“. Проверката на КС разкри, че бюлетините в седем секции са изчезнали, въпреки че трябва да се пазят. 

Какво ли би станало, ако бяха проверени всички изборни секции, остана въпрос на догадки и хипотези.

Когато и да е замислила блокирането на опитите за честни избори, властта в оставка изглежда готова да воюва. Отхвърли предложението на ПП–ДБ за 100% машинен вот, подкрепено и от останалата опозиция в парламента, както и от президента, при това изчаквайки да отмине протестът, призовал отново за гласуване с машини.

Честни избори ще отмият в канавката две от партиите – БСП и ИТН, и със сигурност ще ударят по резултатите на ГЕРБ–СДС и ДПС – Ново начало. Онова, с което „броячите“ няма да могат да се справят, е висока избирателна активност и ефективни действия на МВР преди и в деня на вота. Първото зависи от гражданската позиция на избирателите, второто – от служебния премиер. Време е политическите машини за избори да бъдат разглобени и унищожени.

Какво става в Сърбия? Непредвидимото бъдеще

Post Syndicated from Джорджа Спадони original https://www.toest.bg/kakvo-stava-v-surbiya-nepredvidimoto-budeshte/

Какво става в Сърбия? Непредвидимото бъдеще

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

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

„От този прозорец в късната сутрин на 12 март 2003 г. снайперист стреля и убива Зоран Джинджич, докато той влиза през служебния вход на сградата отсреща.“

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

„Всеки сърбин, който е бил достатъчно възрастен тогава, си спомня точно къде се е намирал и какво е правил в онази мартенска сутрин, когато е получил новината. Това е нашият 11 септември. Денят, в който всеки от нас разбра, че вратите на света около нас, едва открехнати, отново се затварят. И че пак пропускаме възможността за нормално развитие на тази държава.“

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

Случаят „Джинджич“

Още като студент в Белград Зоран Джинджич показва прагматично мислене, политическа интуиция, нюх за духа на времето и ораторски талант. През 70-те години е изхвърлен от университета и по-късно арестуван и осъден за организирането на независимо студентско движение. Емигрира във Федерална република Германия, където през 1979 г. защитава докторат по философия.

Когато се връща в Югославия през 1989 г., с други интелектуалци и активисти основава Демократическата партия (Demokratska stranka). Една година по-късно става неин ръководител и депутат от опозицията, макар мнението му по вечните въпроси на сръбския национализъм да е понякога неясно (през 1994 г. например посещава в Пале президента на Република Сръбска Радован Караджич, за да „изрази своята солидарност със сърбите от Босна“).

През 90-те Джинджич се отличава като ключова фигура в протестите срещу режима на Слободан Милошевич. През 1997 г. опозиционната коалиция Zajedno, в която е и Демократическата партия, се разпада след бойкот на изборите през декември и от други демократични групи. Избухването на войната в Косово през 1998 г. и бомбардировките на НАТО над Сърбия през 1999 г. бележат началото на края за Милошевич. В същото време обаче започва серия убийства, над които пада сянката на президента – от журналиста Славко Чурувия до министъра на отбраната Павле Булатович, от паравоенния командир Желко Ражнатович – Аркан до бившия президент Иван Стамболич.

През септември 2000 г. улиците на страната отново са изпълнени с протестиращи, след като не е призната победата на президентските избори на кандидата на демократичната опозиционна коалиция (Demokratska Opozicija Srbije) Воислав Кощуница. След седмица масови протести на 5 октомври 2000 г. Милошевич подава оставка. Парламентарните избори през декември са спечелени от Демократическата партия с 64,7%. На 25 януари 2001 г. Джинджич става министър-председател – надеждата за промяна се разпростира из страната, окрилена от очакванията от чужбина.

Какво става в Сърбия? Непредвидимото бъдеще
Агитационни материали на различни сръбски партии и политически фигури, явявали се на избори между 1990 и 2000 г © Джорджа Спадони

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

Но докато на международно ниво Зоран Джинджич създава положителен имидж, в Сърбия е все по-противоречиво приеман от определени слоеве на обществото и от институциите. Първоначално той е против екстрадицията на Слободан Милошевич в Хага, но през април 2001 г. изиграва ключова роля в ареста му от югославските власти. На 28 юни обаче, въпреки възраженията на Конституционния съд, Джинджич разпорежда екстрадицията на бившия президент в Нидерландия под натиска на САЩ, които заплашват да не отпуснат планираната икономическа помощ от Световната банка и Международния валутен фонд.

Въпреки това Зоран Джинджич не е убит заради неприязънта на националистите. Онзи единствен куршум, пронизал го право в сърцето, е изстрелян от Звездан Йованович, член на „Червените барети“, водещи началото си от Сръбската доброволческа гвардия и по-късно влели се в специалните сили на Службата за държавна сигурност на Сърбия.

Джинджич е убит заради твърдото си намерение да се бори срещу Земунския клан – една от най-мощните престъпни организации в държавата. Същата, която още от 90-те е в тесни връзки със сръбската власт и с чиито представители самият Джинджич се вижда дни преди оставката на Милошевич, получавайки гаранции, че техните формирования няма да пречат на прехода. А мафията, както знаем, е държава в държавата. Това е напълно съзнателна сделка с наследството на Милошевич, пуснало пипалата си навсякъде.

Убийството на Зоран Джинджич е планирано в заговор между тайните служби, организираната престъпност и част от политическите фигури, останали след Милошевич.

Месец преди смъртта му тогавашната главна прокурорка на Хагския трибунал Карла дел Понте се среща с него: 

Разказа ми [Зоран Джинджич – бел. ред.] в подробности за реформаторската си програма. И тогава изведнъж ми каза: „Ще ме убият.“ 

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

Джинджич ми обясни как възнамерява да се намеси в армията и полицията, след като е променил икономическата система. Реформата изискваше да се пипа изключително внимателно и беше доста опасна. И министър-председателят беше напълно наясно с това.

Ето как историчката Дубравка Стоянович анализира случилото се в своя статия, публикувана 10 години след убийството на Зоран Джинджич:

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

Може би налице беше и намесата на Великите сили. И преди всичко – същото онова разделение на модернисти и антимодернисти, про- и анти-Запад, което е основната причина за повечето атентати в сръбската история. Ето защо убийството от 2003 г. доказва, че има приемственост, произтичаща от дълбоките проблеми в новата история на Сърбия: слабостта на институциите, мощта на „неконтролираните фактори“, олигархично-партийната държава и нерешения ключов въпрос „А сега накъде?“. 

И като се взираме в днешното положение в страната след още десет години (а и повече), не само че хич не изглежда по-светло, но и не е толкова различно.

Какво става в Сърбия? Езикът на протестите – музика и архитектура
Джорджа Спадони е на обиколка из Белград с нова група туристи, на които разказва за музиката и архитектурата на града, а през този разказ – и на нас за случващото се в Сърбия. Това е втора част от поредицата, посветена на годишнината от трагедията в Нови Сад и на протестите за промяна.
Какво става в Сърбия? Непредвидимото бъдеще

Демокрация или стабилокрация

9 август 2024 г. Чакаме на границата между Босна и Сърбия. Обиколката ни е към края си, прибираме се в Белград, или поне се опитваме. Опашката е безкрайна, безмилостното лятно слънце превръща микробуса в печка, климатикът е почти безпомощен. Групата шумно решава кръстословици, а с колегата ми и шофьора говорим за масовите протести, предвидени в столицата за следващия ден – 10 август.

Бетонната козирка на гарата в Нови Сад, официално открита преди месец, ще издържи още малко. Причината за протеста е друга – проектът за най-голямата литиева мина в Европа, която англо-австралийската компания „Рио Тинто“ възнамерява да разработва в Лозница, до река Ядар, в западната част на страната. Спрян благодарение на огромните протести през 2022 г., планът отново е върнат на дневен ред от сръбското правителство през юли 2024 г. С подкрепата на ЕС.

Най-накрая излизаме от Босна, но не и преди да сме подарили шоколадово блокче на полицая, който, след като ни провери документите, изрично ни поиска такъв странен и сладък подкуп. Влизаме в Сърбия и минаваме точно през местността, застрашена от минните амбиции. Няколко метра след границата ни приветства огромен плакат на управляващата Сръбска прогресивна партия (СПП, Srpska napredna stranka), от който ни гледа мъж с очила и дебели устни. Шофьорът и колегата ми не се въздържат и отправят немалко псувни към този лик, който всъщност принадлежи на Александър Вучич – главния герой в сръбската политика от повече от десетилетие.

Роден е през 1970 г. в Белград и на 23 години се присъединява към Сръбската радикална партия (СРП, Srpska radikalna stranka) – ултранационалистическа формация, която иска да създаде „Велика Сърбия“ от руините на Югославия. Той става протеже на партийния лидер Воислав Шешел, осъден за военни престъпления в Хага. През 1998 г. Вучич е назначен от самия Слободан Милошевич за министър на информацията, като само за две години успява да приложи едно от най-репресивните законодателства в Европа срещу медиите и свободата на словото.

След 5 октомври 2000 г., когато Милошевич подава оставка, СРП е в опозиция, докато се редуват белязани от скандали демократични правителства, които включват присъединяването към ЕС в своите програми. Точно покрай въпроса за ЕС СРП се разделя и част от членовете ѝ начело с Томислав Николич и Александър Вучич я напускат, за да създадат Сръбската прогресивна партия (СПП) през 2008 г. Въпреки името и декларираните проевропейски настроения формацията е силно консервативна и популистка и бързо се превръща в основната опозиционна сила. На парламентарните избори през 2012 г. СПП печели 25% от гласовете и се класира на първо място. Вучич е първо министър на отбраната, а после – вицепремиер. На предсрочните парламентарни избори през 2014 г. СПП удвоява подкрепата си до почти 50% и печели мнозинство в парламента. Тогава Вучич става министър-председател.

Междувременно той признава в интервю „грешките от младостта“ и се отдалечава от националистическите уклони отпреди години, когато публично защитава Ратко Младич и Радован Караджич. Сред амбициите му за Сърбия е присъединяването към ЕС. Всъщност, въпреки че либералните партии, предшестващи СПП, полагат основите на европейските стремежи на Сърбия, именно Вучич дава официален старт на процеса през 2014 г. Следващите предсрочни избори през 2016 г. са предизвикани от СПП точно с цел подкрепа за продължаване и успешно приключване на процеса по кандидатстване за членство в ЕС. Този път СПП събира над 50%, но опозицията заявява, че гласовете са били купени.

В чужбина обаче се повишава задоволството от стабилността, която Сърбия най-накрая демонстрира. Особено в Германия. В интервю от 2016 г. Вучич казва, че смята Ангела Меркел „за истинския лидер на Европа“ и че германската канцлерка „се грижи за Балканите“. Критиците на управлението обаче посочват, че привидната стабилност в страната е постигната за сметка на демократичните ценности, особено на медийната свобода.

Какво става в Сърбия? Непредвидимото бъдеще
Александър Вучич по време на посещение в Москва през 2017 г. Източник: Wikimedia

Изборите през 2017 г., с които Вучич започва своята кариера като президент на Република Сърбия, също са белязани с все по-строг контрол върху медиите и постепенно разрушаване на върховенството на закона. Междувременно, за да продължи да гради „прогресивен“ имидж за пред международната общност, президентът назначава за министър-председател Ана Бърнабич – първата жена на този пост в Сърбия, и то открита лесбийка. Без това да означава, че в програмата на правителството има място за правата на ЛГБТ, напротив – ролята на Бърнабич ѝ осигурява редица привилегии, от които останалата част от ЛГБТ хората в страната е лишена. 

Какво става в Сърбия? Непредвидимото бъдеще
Ана Бърнабич. Източник: Wikimedia

През 2020 г. неправителствената организация „Фрийдъм Хаус“ потвърждава влошаването на положението в балканската страна, която вече не е демокрация, а хибриден режим, особено след резултатите от новите президентски избори през юли, които СПП печели с над 60%. Тази авторитарна тенденция, започнала през 2012 г., превръща държавата в стабилокрация, която въпреки реториката на правителството не е гарант за стабилността в Балканския регион, както вече стана ясно от нестихващите протести, започнали през 2024 г.

Сърбия вън от ЕС, ЕС вън от Сърбия

10 август 2024 г. Обиколката приключва, изпращаме гостите преди началото на протестите, предвидено за 19:00. Тръгваме около час по-рано и улиците вече се пълнят с хора, които се изливат от всички страни. В рамките на половин час центърът на Белград е изцяло блокиран – граждани от всички възрасти, с кучета и детски колички, с плакати и свирки са се събрали с мирни намерения и лошо настроение. Сред слоганите се чете „Рио Тинто марш от Сърбия“, „Няма да копаете“, „ЕС диктува, Вучич изпълнява, Рио Тинто печели“. Колегата ми казва: 

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

Всъщност тактиката на президента на международно ниво е да поддържа добри отношения с конкурентни геополитически сили. Твърди, че иска Сърбия да продължи своя европейски път, но в същото време поддържа приятелски отношения с Русия и привлича в страната най-големия брой китайски проекти в Европа в рамките на глобалната китайска стратегия за сътрудничество „Един пояс – един път“. В резултат на това, от една страна, отказва да подкрепи санкциите срещу Москва след избухването на войната в Украйна, въпреки че Сърбия има статус на кандидат-членка на ЕС; от друга, възлага все повече поръчки без конкурс на спорни китайски компании.

Една година след трагедията в Нови Сад. Какво става в Сърбия?
На 1 ноември се навършва една година от трагедията в Нови Сад, която провокира някои от най-големите протести в Сърбия, а и в региона ни. Италианката Джорджа Спадони, която обича и познава Балканите, ни разказва в няколко поредни материала как изглеждат Белград и цялата страна година по-късно.
Какво става в Сърбия? Непредвидимото бъдеще

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

Сред последните удари по доверието към Съюза е откровеното насърчаване на проекта на „Рио Тинто“ в Лозница, който даже е представен като стратегически проект на ЕС през 2025 г. Освен това слабата реакция от Брюксел спрямо мащабната вълна от антиправителствени протести, провокирана от трагедията в Нови Сад, играе важна роля в спада на доверието на сърбите към ЕС.

През октомври 2025 г. Европейският парламент прие резолюция, призоваваща за правото на мирни протести в Сърбия и изискваща политическа отговорност за засилените репресии. Ефективността на тези призиви обаче е доста ограничена и е застрашена от все по-влиятелната крайна десница, която подкрепя Вучич. Един месец по-късно „Рио Тинто“ обяви, че проектът „Ядар“ ще бъде поставен в режим „грижа и поддръжка“ поради липса на разрешителни и напредък, както и заради силна местна съпротива. Но това вероятно няма да е краят на историята и е все по-трудно да се предвиди какво крие бъдещето за балканската държава.

Какво става в Сърбия? Непредвидимото бъдеще
16 минути мълчание за 16-те жертви от трагедията в Нови Сад година по-късно © Джорджа Спадони

2025 г. Ден преди да покажем на туристическата група мястото, където е убит министър-председателят, се събираме около неговата паметна плоча на гробищата. Над черния мрамор, под надписа „Д-р Зоран Джинджич 1952–2003“, намираме леко повехнал венец от цветя, завързан с лента. Вятърът я е обърнал. Навеждам се и я премествам, за да видя дали пише нещо. Само едно кратко изречение: Hvala za viziju („Благодарим за визията“).

Срещу входа на Философския факултет в Белград – мястото, откъдето всеки път започваме нашите обиколки – погледът на бившия първи министър, напръскан с червена боя, все още се взира в студентите и минувачите. До неговото лице все още може да се разчете излющеното Gledajte u budućnost… („Гледайте в бъдещето…“) – колкото и мътно и страшно да изглежда. Защото друга опция няма.

Т.Е. от Е.Т. – епизод 37

Post Syndicated from Тоест original https://www.toest.bg/t-e-ot-e-t-epizod-37/

Т.Е. от Е.Т. – епизод 37

Навлизаме в новата година плавно и полека с включвания от Доналд Тръмп, Бойко Борисов, Слави Трифонов и други симпатяги.


Следете видеорубриката на Елена Телбис за „Тоест“ и във Facebook, Instagram и TikTok.

The collective thoughts of the interwebz