Introducing the Landing Zone Accelerator on AWS Universal Configuration and LZA Compliance Workbook

Post Syndicated from Kevin Donohue original https://aws.amazon.com/blogs/security/introducing-the-landing-zone-accelerator-on-aws-universal-configuration-and-lza-compliance-workbook/

We’re pleased to announce the availability of the latest sample security baseline from Landing Zone Accelerator on AWS (LZA)—the Universal Configuration. Developed from years of field experience with highly regulated customers including governments across the world, and in consultation with AWS Partners and industry experts, the Universal Configuration was built to help you implement security and compliance at scale for on your regulated workloads. By setting a high bar with the latest AWS security best practices, the Universal Configuration can help address technical control requirements from compliance frameworks across different geographic regions and industry verticals. The Universal Configuration’s multi-account security architecture provides a foundation to host your diverse workload requirements today along with providing the ability to explore the generative AI and agentic AI solutions that will shape your organization in the future. It can also replace months of complex planning and design by deploying a comprehensive security and compliance-driven environment based on AWS Well-Architected principles in a matter of hours.

As organizations grow, they typically pursue or must adhere to new security compliance certifications. LZA and the Universal Configuration help organizations of all sizes and phases in their security and compliance journey. The speed of deployment, step-by-step documentation, and compliance resources can reduce traditional assessment and authorization timelines by months and result in more predictable and successful audit outcomes. This enables more freedom to invest resources to grow the business instead of choosing between security and compliance tradeoffs.

The Universal Configuration helps organizations:

  • Automate the deployment of a secure multi-account AWS environment
    • Foundational security controls based on AWS Well-Architected best practices
    • Apply consistent and predictable security controls post-deployment
    • Enable and integrate with native AWS security, identity, and compliance services
  • Implement controls across system layers
    • Organization-wide security architecture
    • Perimeter and resource-specific preventative, proactive, and detective controls
    • Support for multi-AWS Region resilience, disaster recovery, and active failover
  • Establish a foundation for security and compliance readiness
    • Built-in AWS security best practices and technical implementation statements
    • Map LZA capabilities across global and industry-specific compliance frameworks
    • Deploy hundreds of controls hours instead of months

The LZA Compliance Workbook

The LZA engine has been a trusted tool for quickly deploying secure multi-account AWS environments for over 4 years. It is also cost effective because you pay only for the AWS services used to operate your environment. The Universal Configuration is the first sample configuration accompanied by the LZA Compliance Workbook available on AWS Artifact. It’s a first-of-its-kind resource with detailed control mappings showing how the Universal Configuration can help you address requirements from frameworks including NIST 800-53 Rev5, CMMC/NIST 800-171, ISO-27001, HIPAA, C5:2020, NATO D-32 (Appendix B), and DoD CCI.

The LZA Compliance Workbook is regularly maintained to reflect the latest Universal Configuration baseline and will include additional compliance mappings in future releases. The workbook contains detailed security configuration descriptions based on the Universal Configuration deployment files, along with control requirement mappings and implementation statements that translate its security capabilities into a compliance-friendly format. By combining AWS security best practices with global compliance expertise, the Universal Configuration delivers predicable security outcomes while also helping you meet regional and industry requirements.

Getting started

To get started with the Landing Zone Accelerator on AWS Universal Configuration, the LZA Implementation Guide walks you through the steps, use cases, and considerations when deploying with LZA. You can download the LZA Compliance Workbook from AWS Artifact today and configure notifications to receive emails when future versions are released. You can view the deployment files and additional technical implementation guidance on the GitHub Universal Configuration sample and documentation page. Additionally, visit the AWS Partner Network (APN) for help with audit and advisory initiatives, cloud migrations, deploying the LZA Universal Configuration, and other services. You can visit the AWS Partner Finder tool and search by solution for Landing Zone Accelerator for the latest LZA Partner offerings.

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

Kevin Donohue

Kevin Donohue

Kevin is a Senior Security Compliance Engineer at AWS, where he builds solutions and resources to help AWS customers achieve their security and compliance goals. Prior to joining the Landing Zone Accelerator team in AWS Professional Services in 2024, Kevin began his tenure with AWS Security in 2019 specializing in FedRAMP compliance and the shared responsibility model.

Christine Screnci

Christine Screnci

Christine is a Principal Technical Product Manager at AWS, where she specializes in developing and scaling enterprise-level solutions. Christine began her tenure with AWS in 2016 working with Worldwide Public Sector customers to improve the migration and modernization journey through globally scaled solutions. She is passionate about hypothesis-driven development and experimentation to improve customer experiences with AWS technologies.

Bhavish Khatri

Bhavish is a Senior Delivery Engineer at AWS, where he builds enterprise-scale solutions to help large organizations achieve their compliance goals. Bhavish started at AWS in 2018, specializing in multi-account AWS deployments and focusing on LZA and the Universal Configuration solution. He helps organizations build secure, scalable cloud environments that align with global compliance frameworks and regulatory requirements across diverse sectors.

Transfer data across AWS partitions with IAM Roles Anywhere

Post Syndicated from Jennifer Paz original https://aws.amazon.com/blogs/security/transfer-data-across-aws-partitions-with-iam-roles-anywhere/

Transfer across AWS Cloud partitions. Different identity planes. Long-lived IAM user credentials.

As an enterprise customer, you might need to bring together security, operational, and compliance data from multiple AWS partitions. Creating a holistic view of these types of data is critical to support operations and applications but understanding how to accomplish this while maintaining compliance can be a challenge.

In this post, we show you a past method for securing cross-partition data movement using AWS Identity and Access Management (IAM) user keys and why that’s no longer recommended. We continue by showing you the recommended best practice of using AWS IAM Roles Anywhere to support cross-partition data movement.

Security and compliance and AWS Regions and partitions

Before you begin, it’s important to understand how AWS Regions and partitions are designed. AWS partitions are hard boundaries designed to meet isolation requirements for compliance purposes and consist of one or more Regions, with each partition controlled by an independent instance of IAM. AWS provides multiple partitions; AWS Commercial Regions use an aws partition identifier within the Amazon Resource Name (ARN), AWS GovCloud Regions use an aws-us-gov partition identifier, and the AWS China Regions use an aws-cn partition identifier. AWS account IDs and Region designations are reserved to make sure that they exist only within that respective AWS partition. The IAM instance profile, within each AWS partition, prohibits the creation of trust policies that cross partitions. If you attempt to construct a cross-account trust policy across two partitions, they will receive a CREATE_FAILED error as shown in Figure 1. This isolation between partitions is part of the security that we provide our customers.

Figure 1: Failure message for cross partition trust policy

Figure 1: Failure message for cross partition trust policy

It’s critical that you understand your compliance requirements and build a unified dashboard and workflows in the appropriate partition. For example, data should only flow from the AWS Commercial partition to the AWS GovCloud partition—not the other way around. To adhere to the FedRAMP boundary policy FRR211, data about workloads within the AWS GovCloud partition should not be shared with AWS Commercial partition. Thus, it’s a best practice when you create a unified dashboard and automation to design the architecture and solution to operate within the AWS GovCloud partition. This approach enables a consolidated view of your security and cloud operations. From this centralized data plane, automated remediations, notifications, and escalations can be triggered by using Amazon EventBridge against data collected from Commercial and GovCloud Regional resources. These automated workflows can be used for operational triage within a ticketing system (such as Service Now or Atlassian JIRA), security detections within a cloud-native application protection platform (CNAPP) (such as AWS Security Hub or CrowdStrike), and application alerting from enterprise notification systems (such as Slack, Microsoft Teams, or email).

In addition to data partition isolation, it’s a FedRAMP security best practice to make sure that the credentials used to access GovCloud Regions are isolated to exist only within those Regions. It’s also a best practice to make sure that data access requests originate from the GovCloud partition, and to pull data from the less restrictive partition, such as the aws Commercial partition. This requirement is designed to help prevent exposure of GovCloud partition resources to the Commercial partition through open ports, APIs, endpoints, or credentials to a commercial partition. Because AWS Commercial partition resources can support connectivity from the internet, you can put appropriate security controls to limit access to endpoints, ports, APIs and load balancers using short-term or long-term credentials.

Cross-partition data transfer using IAM access keys (Not recommended)

Though this is no longer a recommended best practice, data transfer requirements were met previously by using Data Sync, s3api, data transfer hub, and other SDK methods by creating an IAM user access key in the AWS Commercial partition. You would then store the aws partition IAM user access key in AWS Secrets Manager in the aws-us-gov partition. By using this method, one of these applications would operate within AWS GovCloud; the application would then use the aws partition IAM user access key to access and read data from the commercial partition Amazon Simple Storage Service (Amazon S3) bucket and then write it to the AWS GovCloud Partition S3 bucket. The application could then process the data within the application running in the AWS GovCloud partition. That legacy architecture is shown in Figure 2.

Figure 2: Cross-partition data movement using IAM access keys

Figure 2: Cross-partition data movement using IAM access keys

This solution requires an audit exception to allow the use of long-term user credentials. Using long-term user credentials for workloads or service accounts deviates from AWS security best practices and NIST 800-53 IA2, because they can be compromised and difficult to rotate and change. Temporary credentials align with AWS security best practices and are provided by AWS roles. Additionally, the use of x509 certificates has been a standard for establishing secure communications with applications operating processes on remote devices and comply with NIST 800.53r5 IA8.

Cross-partition data transfer using IAM Roles Anywhere (Recommended)

To meet the requirement to use short-term credentials and enable access across an AWS partition, you can use IAM Roles Anywhere, which avoids the need for long-term access key or secret access key credentials. Using IAM Roles Anywhere, you can use your existing certificate authority (CA) or AWS Private Certificate Authority to issue and manage X.509 certificates to specific workloads and applications. You can register your external CA with IAM Roles Anywhere as a trust anchor to establish a trust between your external CA and IAM Roles Anywhere. If you don’t manage your own private key infrastructure (PKI), a trust can be established with AWS Private CA to create a CA as the trust anchor. For detailed steps for setting up IAM Roles Anywhere, see Planning for your IAM Roles Anywhere deployment.

Figure 3: Architecture for cross-partition data movement using IAM Roles Anywhere with an external CA

Figure 3: Architecture for cross-partition data movement using IAM Roles Anywhere with an external CA

Figure 3 demonstrates how you can use IAM Roles Anywhere with an external CA to enable data transfer between partitions. By using this pattern, which is an AWS security best practice, you can pull data from your AWS Commercial partition into your AWS GovCloud partition. By using an external CA, you can use your existing PKI. For compliance purposes, internal CAs are often required to issue certificates for internal applications and services, device authentication, internal web services, employee authentication, and other tasks. Internal PKI consists of a root CA, intermediate CA and an issuing CA. The root CA is often disconnected from the internet to help prevent tampering or issuing of PKI to untrusted resources. The root CA will issue a certificate for an intermediate CA and the intermediate CA will create certificates for one or more issuing CAs. When the GovCloud application creates a certificate signing request (CSR), it will maintain the private key that goes with the CSR in Secrets Manager. The customer’s external issuing CA will then sign the CSR and provide an end-entity certificate for the GovCloud application in addition to the external CA bundle. This CA bundle contains the root CA, intermediate CA, and issuing CA certificates. All three of which will be stored in GovCloud application’s Secrets Manager so that the workload can then interact with AWS Commercial partition resources.

As shown in Figure 3 you can initiate a temporary session from GovCloud (right) to AWS Commercial (left). IAM Roles Anywhere is configured within the Commercial partition to use your existing PKI as the trust anchor. As you vend PKI certificates to workloads that run in GovCloud, they’re stored in Secrets Manager, and your Amazon Elastic Kubernetes Service (Amazon EKS) role allows access to the certificates. In the Commercial Region, you configured a role that allows access to Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS), and Amazon S3. You then configure the trust policy on that role to allow IAM Roles Anywhere access. Based on your GovCloud application scheduling, the Amazon EKS pipeline provides the credential helper process temporary security credentials for the Commercial Region. It does this by using the certificates, private key, Commercial Region IAM Roles Anywhere role ARN, profile ARN, and trust anchor ARN that are provided to the GovCloud application as it prepares to connect from the GovCloud Region to the Commercial Region.

Figure 4: Cross-partition data movement using IAM Roles Anywhere with AWS Private CA

Figure 4: Cross-partition data movement using IAM Roles Anywhere with AWS Private CA

If you don’t have an existing PKI in place, or don’t want to build your own offline PKI, you can use AWS Private CA, as shown if Figure 4. Using AWS Private CA, you don’t have to maintain hardware or software. As a managed service, AWS handles the high availability, scalability, and durability, in addition to patching and maintenance. You also benefit from seamless integration with other AWS services such as AWS Elastic Load Balancing, Amazon CloudFront, and Amazon API Gateway. AWS Private CA also integrates with AWS CloudTrail, so that you can audit what actions have been taken.

Conclusion

In this post, we explained the compliance requirements that need to be considered when migrating data across AWS partitions. We also outlined architectural options AWS customers and partners can take when implementing a solution to address this need.

IAM Roles Anywhere is a great solution that AWS Customers and software as a service (SaaS) partners can use when they want to access AWS resources from across AWS partitions without needing to use long-lived credentials for IAM users.

To learn more about IAM Roles Anywhere, see the feature’s documentation, this IAM Roles Anywhere workshop, or this re:Inforce presentation featuring Hertz.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on AWS Security, Identity, and Compliance re:Post or contact AWS Support.

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

Jenn Reed

Jenn Reed

Jenn is Principal Security Solutions Architect at AWS and former CISO, with over 30 years of security and software development experience and 12 years of experience building on AWS. She lives in Ann Arbor, Michigan, and enjoys running, playing ukulele, and reading science fiction novels.

Bill Wells

Bill Wells

Bill is a Senior Solutions Architect at AWS with over 20 years of experience beginning in the U.S. Air Force. Leveraging his diverse IT background across multiple organizations, Bill specializes in architecting secure, compliance-aligned cloud solutions that help Federal Partners achieve business outcomes using AWS services.

Enforce business glossary classification rules in Amazon SageMaker Catalog

Post Syndicated from Ramesh H Singh original https://aws.amazon.com/blogs/big-data/enforce-business-glossary-classification-rules-in-amazon-sagemaker-catalog/

Organizations are scaling their data catalogs faster than ever. Maintaining consistent metadata standards across teams remains a challenge. Business glossaries define the language of the enterprise—terms like Customer Profile, Transaction, or Confidential Data—but assets are often published without these classifications, leading to inconsistent metadata and poor discoverability.

To address this, Amazon SageMaker Catalog now supports metadata enforcement rules for glossary terms classification (tagging) at the asset level. With this capability, administrators can require that assets include specific business terms or classifications. Data producers must apply required glossary terms or classifications before an asset can be published. This enforces metadata consistency across the catalog and makes sure assets carry the business context needed for effective discovery and governance.

This capability builds on existing metadata rule features for enforcing required metadata fields during asset publishing. The new addition extends those rules to cover glossary term validation, strengthening the link between business language and technical data assets.

In this post, we show how to enforce business glossary classification rules in SageMaker Catalog.

Why metadata enforcement matters

A common governance challenge is the lack of standardized tagging and classification for assets entering enterprise catalogs. Without enforcement, data producers might publish assets missing required business terms (such as data sensitivity level or product domain), resulting in inconsistent metadata that confuses business users, unreliable search and filtering results, and manual cleanup and downstream compliance risks.

By automatically validating metadata at publish time, SageMaker Catalog validates metadata when assets are published. This offers the following key benefits:

  • Assets are classified with approved business terms before publication
  • Validation supports compliance with internal glossary and classification standards
  • Consistent tagging enhances search accuracy and reduces noise
  • Incomplete or incorrectly tagged assets don’t reach consumers

How metadata enforcement works

On the Amazon SageMaker Unified Studio console, administrators navigate to Catalog, Governance, Rules and create metadata rules targeting the asset publishing workflow. Rules can specify required glossary terms or classification fields (for example, Business Unit, PII Category, or Data Sensitivity). Rules can apply organization-wide or within specific domains or projects.

When a producer attempts to publish an asset, SageMaker Catalog checks that the asset includes the required glossary terms or classifications. If any required metadata is missing, the publish action fails with a clear error message. After the metadata is added, the asset can be published successfully.

Enforced tagging makes sure published assets can be searched and filtered using consistent business terminology, improving catalog usability for analysts and business users.

Solution overview

For this post, we explore a financial services use case. Our example a financial services company defines a rule requiring all datasets published from the project to have ‘Finance’ glossary associated:

  • A data producer attempting to publish a new dataset without this tag receives a validation error
  • After applying the correct classification, the dataset publishes successfully
  • Analysts can now filter the catalog to find only Finance datasets or join assets consistently tagged with the same glossary term

In the following sections, we walk through the steps to configure this solution. We create a rule that all assets published from a specific project should have a business unit tag called Finance.

Prerequisites

To test this solution, you should have a SageMaker Unified Studio domain set up with a domain owner or domain unit owner privileges. You should also have an existing project to publish assets and catalog assets. For instructions to create these assets, see the Getting started guide.

In this example, we created a project named financial_analysis and a test table. For instructions to create a table, see Get started with Amazon S3 Tables in Amazon SageMaker Unified Studio. To ingest the sample data to SageMaker Catalog and generate business metadata, see Create an Amazon SageMaker Unified Studio data source for Amazon Redshift in the project catalog.

Create glossary and add terms

Complete the following steps to create a new glossary and add terms:

  1. In SageMaker Unified Studio, on the Discover menu, choose Glossaries.
  2. Choose Create glossary.
  3. Provide details for your glossary, including name, owning project, and optional description.
  4. For Glossary restriction, turn on Enabled.
  5. Choose Create.
  6. Create the term Finance in the Business Unit Details glossary.

Create rule to enforce glossary terms

Complete the following steps to create a rule to define glossary terms:

  1. On the Govern menu, choose Domain units.
  2. On the Rules tab, choose Add.
  3. Add a publishing rule for the Finance project to have the Finance tag for all assets published to the catalog.
  4. Choose Add rule.

    The following screenshot shows the configuration details for your new rule.

Publish asset with enforced rules

Complete the following steps to publish your asset with the enforced rules:

  1. On the financial_analysis project page, go to your asset.
  2. In the Glossary terms section, choose Add terms.

    If you choose Publish without adding the needed term, you get an error stating the Finance term should be assigned.
  3. Choose Finance to add the required term.
  4. Choose Publish asset.

The following screenshot shows the published asset and the required terms in the glossary.

Conclusion

With metadata enforcement rules for glossary terms, SageMaker Catalog brings stronger control and consistency to how organizations publish and manage their data assets. By requiring approved business classifications before publication, teams can make sure assets adhere to enterprise metadata standards, improving governance, discoverability, and trust in shared catalogs. This capability helps organizations scale their catalog governance without adding manual overhead—embedding compliance and quality directly into the publishing workflow.

Metadata enforcement rules for glossary terms are available in AWS Regions where SageMaker Catalog operates. Get started with this capability, refer to the user guide.


About the Authors

Ramesh Singh

Ramesh Singh

Ramesh is a Senior Product Manager Technical (External Services) at AWS in Seattle, Washington, currently with the Amazon SageMaker team. He is passionate about building high-performance ML/AI and analytics products that help enterprise customers achieve their critical goals using cutting-edge technology.

Pradeep Misra

Pradeep Misra

Pradeep is a Principal Analytics and Applied AI Solutions Architect at AWS. He is passionate about solving customer challenges using data, analytics, and AI/ML. Outside of work, he likes exploring new places, trying new cuisines, and playing badminton with his family. He also likes doing science experiments, building LEGOs, and watching anime with his daughters.

Pradyut Singh

Pradyut Singh

Pradyut is a Software Development Engineer at AWS, working with the Amazon SageMaker team with a focus on Data and AI services. Outside of work, he has a passion for travel and enjoys going on long road trips, exploring diverse cuisines and discovering new places along the way.

Manny Pelaez

Manny Pelaez

Manny is a UX Designer at AWS working on Amazon SageMaker Unified Studio. He is passionate about creating intuitive user experiences by listening to customers and focusing on their pain points. Outside of work, he enjoys driving, exploring food, art, sketching, and working on side projects. He also teaches a design course, sharing his expertise with aspiring designers.

Enhanced data discovery in Amazon SageMaker Catalog with custom metadata forms and rich text documentation

Post Syndicated from Ramesh H Singh original https://aws.amazon.com/blogs/big-data/enhanced-data-discovery-in-amazon-sagemaker-catalog-with-custom-metadata-forms-and-rich-text-documentation/

Amazon SageMaker Catalog now supports custom metadata forms and rich text descriptions at the column level, extending existing curation capabilities for business names, descriptions, and glossary term classifications.

With these new features, data stewards can define and capture business-specific metadata directly in individual columns, and authors can use markdown-enabled rich text to provide detailed documentation and business context. Both form fields and formatted descriptions are indexed in real time, making them immediately discoverable through catalog search.

Column-level context is essential for understanding and trusting data. This release helps organizations improve data discoverability, collaboration, and governance by letting metadata stewards document columns using structured and formatted information that aligns with internal standards.

In this post, we show how to enhance data discovery in SageMaker Catalog with custom metadata forms and rich text documentation at the schema level.

Key capabilities

SageMaker Catalog now offers the following key capabilities:

  • Custom metadata forms – Data stewards can now use custom metadata forms to capture organization-specific metadata fields for columns such as Business Owner, Regulatory Classification, Units of Measure, or Approved Use Case. Each field is stored as a key-value pair and indexed for search, enabling business-level queries like “find columns where sensitivity = confidential.”
  • Rich text (markdown) descriptions – Each column supports a markdown-enabled description field. Authors can format text with headings, bullet lists, and hyperlinks to add deeper business or operational context—for example, logic definitions, sample values, or data lineage references.
  • Real-time indexing for search – Custom form values and rich text content are indexed as soon as they are saved. Users can search using a metadata value, keyword, or glossary term across columns.

Solution overview

For this post, we explore a financial services use case. Our example financial services organization defines a column metadata form that includes several fields, as illustrated in the following table.

Field Example Value
Approved Use Case Financial revenue modeling
Business Owner Finance Office
Domain RF

For a dataset column named revenue, the author adds the following markdown description:

# Business Revenue

- Use for Financial Modeling
- Use only for batch use cases

When analysts search for Domain = RF, this column appears in results with complete business context.

In the following sections, we demonstrate how to use to use metadata forms for columns and add rich text descriptions that is searchable.

Prerequisites

To test this solution, you should have an Amazon SageMaker Unified Studio domain set up with a domain owner or domain unit owner privileges. You should also have an existing project to publish assets and catalog assets. For instructions to create these assets, see the Getting started guide.

In this example, we created a project named financial_analysis and a test table. To create a similar table, see Get started with Amazon S3 Tables in Amazon SageMaker Unified Studio. To ingest the sample data to SageMaker Catalog and generate business metadata, see Create an Amazon SageMaker Unified Studio data source for Amazon Redshift in the project catalog.

Create new metadata form

Complete the following steps to create a new metadata form:

  1. In SageMaker Unified Studio, go to your project.
  2. Under Project catalog in the navigation pane, choose Metadata entities.
  3. Choose Create metadata form.
  4. Provide an optional display name, a technical name, and an optional description, then choose Create metadata form.
  5. Define the form fields. In this example, we add the fields Domain, Business Owner, and Approved Use Case.
  6. For Requirement Options, select the configuration for each field. For our use case, we select Always required.
  7. Choose Create field.
  8. Turn on Enabled so the form is visible and can be used for assets.

Attach metadata form to column

Complete the following steps to attach the metadata form to a column:

  1. Under Project catalog in the navigation pane, choose Assets.
  2. Search for and select your asset (for this example, we use the asset business_finance).
  3. On the Schema tab, choose View/Edit next to the revenue field.
  4. Choose Add metadata form.
  5. Choose the form you created and choose Add.
  6. Add details for the metadata form fields

Add additional context as formatted text

Next, we enter a rich text description for each column using the markdown editor, including headings, bullet lists, links, and sample values. Complete the following steps:

  1. Choose Edit next to README for the revenue field where you added the metadata form.
  2. Enter details and choose Save.
  3. Choose Preview to view the formatted README at the column level.

Publish and verify search

Now you’re ready to publish the asset. The metadata form values and markdown descriptions become part of the catalog record and are indexed for search. You can also see the history of revisions on the History tab. Other project users can see the metadata form and rich text description for the published assets and subscribe to the data asset. You can create more data products with these assets, and they will also have the column metadata form and README.

In the catalog search UI, data users can now filter on custom form fields (for example, “Domain = RF”) or search in natural language for text that matches the column description.

Best practices

Consider the following best practices when using this feature:

  • Define metadata forms aligned with your business vocabulary (domains, owners, sensitivity levels) proactively before publishing assets at scale.
  • Make column descriptions actionable—include business definitions, value ranges, logic, update cadence, and dependencies.
  • Verify the catalog indexing is timely; publish changes proactively so search results reflect new metadata.
  • Use governance controls. You can combine column-level metadata with existing asset-level templates and approval workflows to enforce publishing standards.
  • Monitor search usage and metadata completeness; target high-value datasets for complete column-level documentation first.
  • Do not store confidential or sensitive information in your metadata forms.

Conclusion

With column-level metadata forms and rich text descriptions, SageMaker Catalog helps organizations deliver higher-quality metadata, stronger governance, and better data discovery. These features make it straightforward for teams to capture complete business context and for analysts to quickly locate and understand the data they need.

Custom metadata forms and rich text descriptions at the column level are now available in AWS Regions where SageMaker is supported.

To learn more about SageMaker, see the Amazon SageMaker User Guide. Get started with this capability, refer to the user guide.


About the Authors

Ramesh Singh

Ramesh Singh

Ramesh is a Senior Product Manager Technical (External Services) at AWS in Seattle, Washington, currently with the Amazon SageMaker team. He is passionate about building high-performance ML/AI and analytics products that enable enterprise customers to achieve their critical goals using cutting-edge technology.

Pradeep Misra

Pradeep Misra

Pradeep is a Principal Analytics and Applied AI Solutions Architect at AWS. He is passionate about solving customer challenges using data, analytics, and AI/ML. Outside of work, he likes exploring new places, trying new cuisines, and playing badminton with his family. He also likes doing science experiments, building LEGOs, and watching anime with his daughters.

Abbas Makhdum

Abbas Makhdum

Abbas is Head of Product Marketing for Amazon SageMaker Catalog at AWS, where he leads go-to-market strategy and launches for data and AI governance solutions. With deep expertise across data, AI, and analytics, Abbas has also authored a book on data and AI governance with O’Reilly. He is passionate about helping organizations unlock business value by making data and AI more accessible, transparent, and governed.

Harish Panwar

Harish Panwar

Harish is a Software Development Manager at AWS in Bangalore, India. He is leading the Catalog engineering team, which is building data and AI governance solutions. Harish is a veteran in Amazon SageMaker, with deep expertise across SageMaker AI and SageMaker Catalog. He is passionate about creating simple and intuitive AI solutions making AI accessible to everyone.

Building multi-tenant SaaS applications with AWS Lambda’s new tenant isolation mode

Post Syndicated from Anton Aleksandrov original https://aws.amazon.com/blogs/compute/building-multi-tenant-saas-applications-with-aws-lambdas-new-tenant-isolation-mode/

Today, AWS announced a new tenant isolation mode for AWS Lambda, that allows you to process function invocations in separate execution environments for each application end-user or tenant invoking your Lambda function. This capability simplifies building secure multi-tenant SaaS applications by managing tenant-level compute environment isolation and request routing for you. As a result, you can focus on your core business logic rather than implementing your own tenant-aware compute environment isolation.

Overview

Lambda runs your function code in secure execution environments that leverage Firecracker virtualization to provide isolation. These execution environments never share or reuse virtual resources (such as vCPU, disk, or memory) across functions, or even across different versions of the same function. However, Lambda can reuse execution environments for multiple invocations of the same function version, as these execution environments are fully set-up and can therefore deliver faster request processing for your functions.

Figure 1. Incoming invocations processed by a collection of execution environments that belong to a single function.

Figure 1. Incoming invocations processed by a collection of execution environments that belong to a single function.

Multi-tenant SaaS applications that handle sensitive tenant-specific data or execute code supplied dynamically by tenants may need a higher degree of isolation—at the individual application tenant level rather than at the function level—for secure code execution and to reduce the risk of cross-tenant data access.

Prior to today’s launch, developers would implement custom solutions, such as SDKs or application logic to manage isolation within function code. This approach was bug-prone, required more work from application development teams, and didn’t ensure isolation at the compute environment level.

Alternatively, developers adopted the approach of creating separate functions per application tenant, replicating the same code across hundreds or thousands of tenants. This approach provided stronger compute environment isolation than sharing compute environments across multiple tenants of the same function, but increased implementation overhead and operational complexity as workloads grew to support a larger number of tenants over time.

Figure 2. Using function-per-tenant model, each tenant’s requests are processed by a separate function.

Figure 2. Using function-per-tenant model, each tenant’s requests are processed by a separate function.

Starting today, AWS Lambda offers a new tenant isolation mode that lets you isolate execution environments used across different tenants of your multi-tenant SaaS applications, even when all of the tenants invoke the same function. When you enable the new tenant isolation mode, you include a tenant identifier with each function invocation. Lambda uses this identifier to route the request to the correct execution environment. As a result, each execution environment is reused only for invocations from the same tenant. This means you still get the performance benefits of warm execution environments, while ensuring that each tenant’s workloads remain isolated.

Figure 3. With the new tenant isolation capability, Lambda creates separate execution environments per tenant for a single function.

Figure 3. With the new tenant isolation capability, Lambda creates separate execution environments per tenant for a single function.

For organizations handling sensitive tenant-specific data or running untrusted code supplied dynamically by end-users, Lambda’s new tenant isolation mode provides the security benefits of per-tenant compute environment separation without the operational complexity of managing individual functions or infrastructure for each tenant.

Example scenario

Consider building a multi-tenant serverless SaaS application. To optimize performance, your function handler can retrieve tenant-specific configuration and data, cache it in memory, and reuse it for subsequent invocations from the same tenant. For example, you might cache tenant-specific database location, feature flags, or business rules that are frequently accessed during request processing. You may store this information within the application runtime process as global variables or as files in the /tmp directory. However, if the underlying execution environment is used to serve multiple tenants, this approach can potentially expose data across tenants.

With tenant isolation mode you can address this risk with much simpler architecture and configuration. This built-in capability makes Lambda an excellent choice for multi-tenant SaaS applications needing isolated compute environments for individual tenants.

Getting Started with Lambda Tenant Isolation Mode

Use the new tenancy-config parameter to configure tenant isolation mode when you create your function. You can only apply this configuration at function creation time; it cannot be updated for existing functions. The following snippet creates a function with tenancy config using the AWS CLI.

aws lambda create-function \
   --function-name my-function1 \
   --runtime nodejs22.x \
   --zip-file fileb://my-function1.zip \
   --handler index.handler \
   --role arn:aws:iam:1234567890:role/my-function-role \
   --tenancy-config '{"TenantIsolationMode": "PER_TENANT"}'

After the function is created, you must provide the tenant ID parameter with each invocation. Lambda uses this identifier to ensure that the execution environment used for a particular tenant is never reused for other tenants. For subsequent invocations from the same tenant, Lambda may reuse the execution environment to optimize performance. Specify this tenant-id parameter as illustrated below:

aws lambda invoke \
   --function-name my-function \
   --tenant-id BlueTenant \
   response.json

The new tenant-id parameter is required for functions using the tenant isolation mode. Function invocations omitting this parameter will fail with an invocation error, as shown below:

aws lambda invoke --function-name multitenant-function out.json

An error occurred (InvalidParameterValueException) when calling the Invoke operation:
The invoked function is enabled with tenancy configuration. 
Add a valid tenant ID in your request and try again.

Lambda makes the tenant ID parameter available through your function handler’s context object. This allows you to access tenant-specific information in your code, for example if you wish to implement custom logic based on the tenant identity, as shown below:

exports.handler = async function (event, context) {
   const tenantId = context.tenantId;

   // Process tenant-specific logic

   return {
      statusCode: 200,
      body: `OK for tenantId=${tenantId}`
   };
};

The following table outlines differences between Lambda functions with and without tenant isolation mode enabled:

Feature Without the new
tenant isolation mode
With the new
tenant isolation mode
Execution environment isolation Isolated per function version. Isolated per end-user or tenant invoking a function version.
Execution environment reuse Can be reused to process all invocations of a function version. Can only be reused to process invocations from the same tenant invoking a function version.
Data stored on local disk and in-memory Potentially accessible across all invocations of a function version. Potentially accessible across invocations from the same tenant. Not accessible for invocations from other tenants.
Cold starts Occur when there are no warm execution environments available to process incoming invocation. Occur when there are no tenant-specific warm execution environments available to process incoming invocation. More cold starts expected due to tenant-specific execution environments.

Integrating with Amazon API Gateway

Amazon API Gateway uses Lambda’s Invoke API to invoke Lambda functions. When using the Invoke API, Lambda expects the tenant ID parameter to be passed using the X-Amz-Tenant-Id HTTP header. You can configure API Gateway to inject this HTTP header into the Lambda invocation request with a value obtained from client request properties such as HTTP header, query parameter, or path parameter. When using Lambda Authorizers, you can obtain the value from authorization context information returned by the authorizer, such as principal ID or JWT claim. See API Gateway documentation to learn how you can return authorization information from Lambda authorizers to be used for the X-Amz-Tenant-Id header value.

Figure 4. Obtaining X-Amz-Tenant-Id header value from authentication sources.

Figure 4. Obtaining X-Amz-Tenant-Id header value from authentication sources.

The following screenshot illustrates API Gateway Lambda integration configuration, where the incoming request to API Gateway includes an x-tenant-id header that is mapped to the X-Amz-Tenant-Id request header to invoke a Lambda function using tenant isolation mode.

Figure 5. Mapping client request header to Lambda tenant-id header.

Figure 5. Mapping client request header to Lambda tenant-id header.

The following code snippet illustrates this configuration implemented with the AWS CDK.

const lambdaIntegration = new ApiGw.LambdaIntegration(fn, {
   requestParameters: {
      // This configures API Gateway to inject X-Amz-Tenant-Id header
      // into downstream requests. The header value is obtained from 
      // x-tenant-id header in the client request.
      'integration.request.header.X-Amz-Tenant-Id': 'method.request.header.x-tenant-id'
   }
});

resource.addMethod('GET', lambdaIntegration, {
   requestParameters: {
      // This enables API Gateway to use the x-tenant-id header value 
      // obtained from the client request. The header name is arbitrary.
      // you can use any other header name. 
      'method.request.header.x-tenant-id': true
   }
});

Tenant-aware observability

For functions using tenant isolation, Lambda automatically includes the tenant ID in function logs when you have JSON logging enabled, making it easier to monitor and debug tenant-specific issues. Note that the tenantId property is available during function invocation, rather than during function initialization. The tenantId property is included for both platform events (like platform.start and platform.report) and custom logs you print in your function code, as shown in the following screenshot:

Figure 6. Lambda function logs with tenantId.

Figure 6. Lambda function logs with tenantId.

Lambda creates a separate CloudWatch log stream for each execution environment. You can use CloudWatch Log Insights to find log streams that belong to a particular tenant by filtering by tenant Id:

fields @logStream, @message
| filter tenantId=='BlueTenant' or record.tenantId=='BlueTenant'
| stats count() as logCount by @logStream
| sort @timestamp desc

You can also retrieve tenant-specific logs across all log streams:

fields @message
| filter tenantId=='BlueTenant' or record.tenantId=='BlueTenant'
| limit 1000

Each log stream starts with function initialization logs followed by the invocation logs. This structure helps you to debug tenant-specific issues and understand the lifecycle of each tenant’s execution environments.

Considerations

When using the new tenant isolation for Lambda functions, consider the following:

  • Each tenant’s execution environments are isolated from other tenants so that tenant-specific data stored on disk or in memory remain separated from other tenants invoking the same Lambda function.
  • All tenants share the function’s execution role. For more fine-grained permissions for individual tenants, consider propagating tenant-scoped credentials from the upstream application components invoking your Lambda function.
  • Your application may experience higher percentage of cold starts, as Lambda processes requests in separate execution environments for each tenant invoking your functions.
  • You pay a fee for each new tenant-specific execution environment created, depending on the memory configured for your function. See Lambda pricing page for details.

Best practices

When using the new tenant isolation mode for Lambda functions, AWS recommends the following best practices:

  • Implement robust tenant ID validation at the application layer to prevent unauthorized access through tenant ID manipulation. Consider using a dedicated service or database to maintain valid tenant IDs.
  • Monitor and audit tenant access patterns regularly to detect potential security anomalies or unauthorized cross-tenant access attempts.
  • Be aware of Lambda concurrency quotas when building multi-tenant applications. You might need to request quota increases based on your tenant count and usage patterns.

Sample code

Follow the instructions in this GitHub repository to provision a sample project in your own account and see the new Lambda tenant isolation mode in action. The sample project illustrates how to integrate a function using the new tenant isolation mode with Amazon API Gateway and propagate tenant identity from client requests.

Conclusion

The new tenant isolation mode for Lambda simplifies building serverless multi-tenant SaaS applications on AWS. By automatically managing application tenant-level compute environment isolation, this capability eliminates the need for custom isolation logic or separate tenant functions, allowing you to focus on the core business logic while AWS handles the complexities of tenant-aware compute environment isolation.

Combined with the existing security features in Lambda, rapid scaling, and pay-per-use pricing, tenant isolation mode makes Lambda an even more compelling choice for modern SaaS applications, whether you’re building new solutions or enhancing existing ones.

To learn more, refer to the documentation for tenant isolation. For details on pricing, refer to Lambda’s pricing page.

How to update CRLs without public access using AWS Private CA

Post Syndicated from Rochak Karki original https://aws.amazon.com/blogs/security/how-to-update-crls-without-public-access-using-aws-private-ca/

Certificates and the hierarchy of trust they create are the backbone of a secure infrastructure. AWS Private Certificate Authority is a highly available certificate authority (CA) that you can use to create private CA hierarchies, secure your applications and devices with private certificates, and manage certificate lifecycles.

A certificate revocation list (CRL) is a file that contains a signed list of certificates revoked before their scheduled expiration date. Certificates can be revoked for a variety of reasons, including unintended key exposure, or because of discontinued use.

AWS Private CA writes CRLs to an Amazon Simple Storage Service (Amazon S3) bucket that you specify. CRLs are public, fully qualified domain names (FQDNs), but you might have requirements for a CRL that is only accessible internally to your organization, or you might have security standards that require all S3 buckets to have Amazon S3 block public access enabled.

The recommended practice for S3 buckets is to enable Block Public Access, which enables only authorized and authenticated AWS accounts to have access to a bucket and its contents. However, because some public key infrastructure (PKI) clients retrieve CRLs across the public internet, a workaround might be necessary to serve CRLs without requiring authenticated client access to an S3 bucket. One recommended solution is to use Amazon CloudFront to provide access to the CRL. This will likely be the best solution for most customers. Our documentation specifically highlights CloudFront as the recommended implementation path. However, you might not be able to use CloudFront or might need another option.

You might need a solution where the CRL lookups don’t traverse the public internet. In this post, we go over two different approaches to achieve this.

Option 1: Relocate CRLs to an internally accessible location

By default, AWS Private CA writes CRLs to an S3 bucket that you specify. This solution consists of moving the CRL to a separate location that is internally accessible to your TLS clients, but not accessible via the public internet such as an on-premises server. A CRL distribution point (CDP) is a link that points to the location of the CRL where revoked certificates appear. However, when private certificates are generated by AWS Certificate Manager (ACM), the CDP universal resource identifiers (URI) in the certificates point by default to the S3 bucket initially specified.

This solution uses a custom CNAME in the CDP to indicate, during certificate generation, the location where the CRL will ultimately be located.

The steps in the solution are as follows:

  1. Select the S3 bucket where the CRL will be stored.
  2. Issue a certificate through the CA with a custom CNAME.
  3. Create an AWS Lambda function that moves the CRL file from the S3 bucket to another specified location.
  4. Create an Amazon Simple Notification Service (Amazon SNS) notification that alerts a user to the success metric of the CRL generation event.

Prerequisites:

For this walkthrough, you must have the following resources ready to use:

  1. An AWS account with:
    • An AWS Identity and Access Management (IAM) role with permissions for Amazon S3, ACM Private CA, Amazon EventBridge, and Lambda
    • An ACM private CA root and subordinate CA configured in the same AWS Region
    • An S3 bucket for the CRL with permissions that allow the AWS Private CA service principal to PutObject, PutObjectACL, GetBucketACL and GetBucketLocation (see the following example bucket policy)
{     
    "Version": "2012-10-17",     
    "Statement": [         
        {             
            "Effect": "Allow",             
            "Principal": {                 
                "Service": "acm-pca.amazonaws.com"             
            },             
            "Action": [                 
                "s3:PutObject",                 
                "s3:PutObjectAcl",                 
                "s3:GetBucketAcl",                 
                "s3:GetBucketLocation"             
            ],             
            "Resource": [                 
                "arn:aws:s3:::<name-of-bucket>/*",                 
                "arn:aws:s3:::<name-of-bucket>"             
            ],             
            "Condition": {                 
                "StringEquals": {                     
                    "aws:SourceAccount": "<account-num-here>",                     
                    "aws:SourceArn": "<subordinate-ca-arn-here>"                 
                }             
            }         
        }     
    ] 
}

2. AWS Command Line Interface (AWS CLI) configured

Deploy:

With the prerequisites in place, you’re ready to deploy the first solution.

To enable CRL distribution:

  1. Use your account to sign in to the AWS Management Console for AWS Private Certificate Authority.
  2. Select the name of your subordinate CA. This should take you to another page with more details.
  3. Scroll down and choose the Revocation configuration tab.
  4. Choose Edit on the top right.
  5. Figure 1: Edit the revocation configuration

    Figure 1: Edit the revocation configuration

  6. Select Activate CRL distribution. Select the CRL S3 bucket you created prior to the walkthrough.
  7. Figure 2: Enter a name for your CRL

    Figure 2: Enter a name for your CRL

  8. Modify the CDP by expanding the CRL settings dropdown. In the Custom CRL Name field, enter the URL where you will eventually move the CRL. This should be a place that is accessible by your internal organization, but not accessible externally. If you use partitioned CRLs, select the Enable partitioning checkbox. To learn more about CRL partitioning, see Plan your AWS Private CA certificate revocation method.
  9. Choose Save changes.

To create an SNS topic and Lambda function:

  1. Go to the Amazon SNS console.
  2. Create a standard SNS topic. Leave all options as default and subscribe an appropriate email to the topic.
  3. Figure 3: Create an SNS topic

    Figure 3: Create an SNS topic

  4. Go to the Lambda console.
  5. Choose Create Function.
  6. Enter a name for your function. Under Runtime, select Python 3.12 from the dropdown.
  7. Figure 4: Create a Lambda function

    Figure 4: Create a Lambda function

  8. Verify that the role associated with your Lambda function has permissions to get objects from the S3 bucket where AWS Private CA places the CRL (set when you configured the revocation details for the CA), copy objects in Amazon S3, then put objects in an S3 bucket (or wherever the new CRL distribution point specified in the certificate custom CNAME will be—for example, an internal-only accessible location), and publish to an Amazon SNS topic. The Lambda function also checks the success metric of a CRL generation event. If the event fails, an SNS topic will notify an admin. If the event is successful, a copy of the CRL in the original S3 bucket is created in the new specified location and an SNS topic will notify an admin.

Example code (Python 3.13):

import boto3 
import json 

def lambda_handler(event, context):     
	#create a s3 client     
	s3 = boto3.client('s3')          

	#create a sns client     
	sns = boto3.client('sns')     
    topicArn = "<sns-topic-arn-here>”     
    
    #get name of the CA from the CW event     
    caID = event['resources'][0].split('/')[-1]          
    status = event['detail']['result']     
    if status == 'success':              
    	
        source = '<ORIGINS3BUCKET>'         
        destination = '<DESTINATION-S3BUCKET>'         
        #See below note for more clarification on S3 CRL paths         
        folder = 'crl/'         
        file = caID + '.crl'         
        key = folder + file              
        
        try:             
        	copySource = {                 
            	'Bucket': source,                 
                'Key': key             
           	}                      
            
            s3.copy_object(                 
            	CopySource=copySource,                 
                Bucket=destination,                 
                Key=file             
          	)             
            response = sns.publish(                 
            	TopicArn=<sns-topicArn>,                 
                Message=f'Successfully moved {key} from {source} to {destination} in {caID}',                 
                Subject="CRL Upload Success"             
          	)                      
            
            return {                 
            	'statusCode': 200,                 
                'body': json.dumps(f'Successfully moved {key} from {source} to {destination} in {caID}')             
          	}                  
    	
        except s3.exceptions.NoSuchKey:             
        	response = sns.publish(                 
            	TopicArn=<sns-topicArn>,                 
                Message=f"Object {key} not found in {source}",                 
                Subject='CRL Upload Failure'             
          	)             
            return {                 
            	'statusCode': 404,                 
                'body': json.dumps(f'Object {key} not found in {source}')             
          	}                  
   		except Exception as e:             
    		print(e)             
        	response = sns.publish(                 
        		TopicArn=<sns-topicArn>,                 
            	Message=f'Error moving object: {str(e)}',                 
            	Subject='Failure Uploading CRL'             
     		)             
			return {                 
    			'statusCode': 500,                 
        		'body': json.dumps(f'Error moving object: {str(e)}')             
  			}     
    else:         
    	response = sns.publish(                 
        		TopicArn=<sns-topicArn>,                 
            	Message=f'Certificate Authority {caID} CRL creation {status}',                 
            	Subject='CRL Upload Failure'             
     		)         
        return {             
        	'statusCode': 200,             
            'body': json.dumps(f'Certificate Authority {caID} CRL creation {status}')         
      	}

Note: By default, the non-partitioned CRL path in S3 is <s3-bucket-name>/crl/<CA-ID>.crl. If you used a custom path, modify the path name to the CRL accordingly. Alternatively, if using partitioned CRLs, the path changes to <s3-bucket-name>/crl/<CA-ID>/<partition_GUID>.crl; in that case, you can loop over each file in the <CA-ID> path to achieve the same effect.

To create an EventBridge that deploys your Lambda function:

  1. Go to the EventBridge console. Under Buses, select Rules.
  2. Choose Create Rule.
  3. Enter a name for your rule. Under Rule Type, select Rule with an Event Pattern and choose Next.
  4. Under Events, select AWS events or EventBridge partner events as the Event Source.
  5. For the Event pattern, select Use pattern form. For the Event source, select AWS services. For Event Type, select ACM Private CA CRL Generation.
Figure 5: Configure the event pattern

Figure 5: Configure the event pattern

  1. Choose Next.
  2. Under Target types, choose AWS Service, and then select Lambda function from the Select a target dropdown and select the function that you created earlier.
  3. Figure 6: Select the Lambda function as the target

    Figure 6: Select the Lambda function as the target

  4. Choose Next. Review your topic, then choose Update rule.
  5. To test the success of the Lambda function:

    1. To test the EventBridge topic, create and revoke a certificate. You can do this using the AWS CLI by getting the serial number of a certificate using openSSL:
      openssl x509 -in cert.pem -noout -serial
    2. Use the following command to revoke the certificate:
      aws acm-pca revoke-certificate —certificate-authority-arn <CA ARN> \ —certificate-serial <SERIAL NUMBER RETURNED IN STEP 1> --revocation-reason “UNSPECIFIED”
    3. To make sure that the Lambda function is triggered, wait 5–30 minutes. Check CloudTrail to make sure that RevokeCertificate was called, then monitor the CloudWatch log of the Lambda function. You should also get a notification message from your SNS topic.
    4. You have now successfully moved your CRL to a new location.

    Option 2: Implement Private CRL Access Through AWS Private CA

    This solution provides private Certificate CRL access within AWS Private CA, avoiding the need for public internet exposure. The design centers on establishing root and subordinate CAs with CRL functionality enabled within a dedicated S3 bucket, combined with a private network infrastructure using Gateway VPC endpoints and private subnets. Security is enforced through an S3 bucket policy that accomplishes three critical objectives:

    • Authorizing essential AWS Private CA permissions
    • Constraining CRL access to a designated Gateway VPC endpoint
    • Explicitly blocking access attempts from other sources.

    The solution includes private DNS zone configuration for proper resolution and can be verified through access testing confirming successful CRL retrieval from private VPC instances while making sure that requests from public instances are denied, maintaining a strictly private PKI.

    1. Create a root CA and subordinate CA with CRL enabled
    2. Configure a dedicated S3 bucket for CRL storage
    3. Issue private certificates through ACM
    4. Set up a VPC with private subnets
    5. Configure a Gateway VPC endpoint for Amazon S3
    6. Set up route tables for local traffic only
    7. Implement an S3 bucket policy with specific permissions
    8. Configure private DNS resolution
    9. Set up access controls through VPC endpoints
    10. Test private access from within the VPC
    11. Verify that public access is blocked

    Prerequisites for CRL solution 2

    For this walkthrough, you must have the following resources available:

    Deploy CRL solution 2

    With the prerequisites in place, you’re ready to use the console and AWS CLI to deploy the solution.

    To deploy the solution:

    1. Go to the AWS Private Certificate Authority console.
    2. In the navigation pane, choose Create a Private CA.
      1. Under Mode options, select General-purpose.
      2. For CA type options, select root.
      3. For the Subject distinguished name options: Fill in at least one of the subject distinguished name options: Organization(O), Organization unit (OU), Country(C), State, Locality name, and Common name (CN).
        Figure 7: Create a private CA (root)

        Figure 7: Create a private CA (root)

      4. Select Key algorithm options, for example, RSA 2046.
      5. Under Certificate revocation options, select Activate CRL Distribution, and select or create an S3 bucket for CRL storage.
      6. Under Pricing, select the checkbox to acknowledge pricing and then select Create CA.
    Figure 8: Configure a private CA (root)

    Figure 8: Configure a private CA (root)

    3. After creating a root CA, repeat all of step 2 to create a subordinate CA, selecting
    Subordinate CA under
    CA options (step 2-b). When completed, both the root CA and subordinate CA will be visible on the Private certificate authority page.

    Figure 9: View of root CA and subordinate CA

    Figure 9: View of root CA and subordinate CA

    With the root CA and subordinate CA in place, the next step is to create a VPC gateway endpoint for S3 access to enable private network communication.

    To create a VPC gateway endpoint:

    1. Go to the Amazon VPC console
    2. In the left navigation pane, select Endpoints, and choose Create Endpoint.
    3. Configure the Gateway VPC endpoint settings:
      1. Enter a descriptive name for your endpoint (optional).
      2. Type: Select AWS services.
      3. Services: Select the service name com.amazonaws.[region].s3 from the list.
      4. Type: Verify that Gateway is selected (automatically chosen for Amazon S3).
      5. VPC: Choose the VPC where you want to create the endpoint.
      6. Route tables: Select the route tables associated with the subnets that need Amazon S3 access.
      7. Policy: Select Full Access or create a custom policy to restrict access to specific S3 buckets or actions.
      8. Review your configuration and choose Create endpoint.
    Figure 10: Gateway VPC endpoint configuration

    Figure 10: Gateway VPC endpoint configuration

    1. Create two private subnets:
      1. In the Amazon VPC console, choose Subnets and then Create subnet.
      2. Select your VPC and enter the subnet details (name, Availability Zone, and CIDR block).
      3. Repeat for the second subnet in a different Availability Zone.
    2. Configure route tables:
      1. Navigate to Route Tables and choose Create route table.
      2. Create and name two route tables for your private subnets.
      3. Associate each route table with its corresponding private subnet.
      4. Make sure that each route table contains only local routes (VPC CIDR).
      5. Remove any routes for internet access (0.0.0.0/0).
    Figure 11: Private route table configuration

    Figure 11: Private route table configuration

    1. You can see now see under Resource Map that the Gateway VPC endpoint provides secure access to Amazon S3 resources within the private network.
    Figure 12: VPC private instance configuration

    Figure 12: VPC private instance configuration

    1. Use the following example code to implement a bucket policy that enforces the following key security controls:
      • Grant AWS Private CA the necessary permissions for certificate management.
      • Restrict CRL access exclusively through the specified VPC endpoint.
      • Explicitly deny GetObject requests not originating from the designated Gateway VPC endpoint.
    Figure 13: S3 bucket policy

    Figure 13: S3 bucket policy

    The following is an example S3 bucket policy for private CA CRL access with VPC endpoint restrictions:

    {     
        "Version": "2012-10-17",     
        "Statement": [         
            {             
                "Effect": "Allow",             
                "Principal": {                 
                    "Service": "acm-pca.amazonaws.com"             
                    },             
                "Action": [                 
                    "s3:PutObject",                 
                    "s3:PutObjectAcl",                 
                    "s3:GetBucketAcl",                 
                    "s3:GetBucketLocation"             
                ],             
                "Resource": [                 
                    "<arn:aws:s3:::BUCKET_NAME>",                 
                    "<arn:aws:s3:::BUCKET_NAME>/"           
                ],           
                "Condition": {               
                    "StringEquals": {                   
                        "aws:SourceArn": "<arn:aws:acm-pca:REGION:ACCOUNT_ID:certificate-authority/CA_ID>",                   
                        "aws:SourceAccount": "<ACCOUNT_ID>"               
                        }           
                }       
            },       
            {           
                "Sid": "Allow Access to CRL",           
                "Effect": "Allow",            
                "Principal": "",             
                "Action": "s3:GetObject",             
                "Resource": "<arn:aws:s3:::BUCKET_NAME/crl/CA_ID.crl>",             
                "Condition": {                 
                    "StringEquals": {                     
                        "aws:SourceVpce": "<VPCE_ID>"                 
                        }             
                }         
            },         
            {             
                "Sid": "Access-to-specific-VPCE-only",             
                "Effect": "Deny",             
                "Principal": "",            
                "Action": "s3:GetObject",           
                "Resource": [               
                    "<arn:aws:s3:::BUCKET_NAME>",               
                    "<arn:aws:s3:::BUCKET_NAME>/"             
                ],             
                "Condition": {                 
                    "StringNotEquals": {                     
                        "aws:SourceVpce": "<VPCE_ID>"                 
                        }             
                }         
            }     
        ] 
    }

    Figure 14: S3 bucket CRL properties

    Figure 14: S3 bucket CRL properties

    Create a private hosted zone:

    1. Go to the Route 53 console.
    2. In the left navigation pane, choose Hosted zones.
    3. Choose Create hosted zone.
    4. Configure the following:
      1. Domain name: Enter s3.amazonaws.com
      2. Description: (optional) enter Private hosted zone for S3 CRL endpoint
      3. Type: Select Private hosted zone.
      4. VPC: For Region, select your VPC’s Region; for VPC ID, select your VPC from the dropdown list.
    5. Choose Create hosted zone.

    Create a record set:

    1. Inside your new private hosted zone:
      1. Choose Create record.
      2. Select Simple routing policy.
      3. Choose Next.
    2. Configure record:
      1. Record name: Enter your S3 bucket name.
      2. Record type: Select A – Routes traffic to an IPv4 address.
      3. Alias: Toggle Yes.
      4. Route traffic to: Select Alias to S3 website endpoint.
      5. Region: Select your Region.
      6. S3 endpoint: Select from dropdown list.
      7. TTL: Leave as default (300 seconds).
    3. Choose Create record.
    Figure 15: Hosted zone details

    Figure 15: Hosted zone details

    Verify configuration:

    1. Go to the Amazon EC2 console and choose Launch instance.
    2. Select Amazon Linux 2.
    3. Choose Instance Type.
    4. Select you VPC and subnet.
    5. Under Network settings, select Create security group, then choose Allow SSH traffic from and enter your IP address.
    6. Choose Launch instance.
    7. After the instance is launched, select the instance and choose Connect.
    8. Select EC2 Instance Connect and choose Connect.

    Test the solution

    To test private access from an EC2 instance within your private VPC, verify CRL access using:
    curl -s https://<bucket-name>.s3.<region>.amazonaws.com/crl/<certificate-id>.crl | openssl crl -text -noout

    If successful, the command completes the following steps, as shown in Figure 16:

    1. Retrieves the CRL from Amazon S3
    2. Decodes it using OpenSSL
    3. Displays comprehensive CRL information including issuer details, update timestamps, revoked certificate list, signature algorithm, and other metadata
    Figure 16: Public access verification

    Figure 16: Public access verification

    To validate your security controls, attempt access from a public EC2 instance using the following command:
    curl https://<bucket-name>.s3.<region>.amazonaws.com/crl/<certificate-id>.crl

    This should fail, receiving an access denied error confirming that the CRL cannot be accessed from the public internet, as shown in Figure 17.

    Figure 17: Access denied error confirming that the CRL cannot be accessed from the public internet

    Figure 17: Access denied error confirming that the CRL cannot be accessed from the public internet

    Conclusion

    In this post, we walked you through two solutions that you can use to make your CRLs accessible to your internal organization, but not publicly available. First, we showed you how to configure a custom CNAME in your CRL distribution point and deploy Lambda functions to automatically copy each newly generated CRL from the default S3 bucket into a private S3 store.

    Next, we showed you a VPC architecture that uses an Amazon S3 VPC gateway endpoint, tightly scoped bucket policies, and private Route 53 DNS zones to make sure that CRL retrieval is confined to your VPC. We also covered the essential IAM and bucket policies that your clients need to access those CRLs securely. You can get started with setting up this solution on AWS Private CA today.

    If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Certificate Manager forum or contact AWS Support.

Rochak Karki

Rochak Karki

Rochak is a Security Specialist Solutions Architect at AWS, focusing on threat detection, incident response, and data protection helping customers build secure environments. Rochak is a US Army veteran and holds a Bachelor of Science in Engineering from the University of Wyoming. Outside of work, he enjoys spending time with family and friends, hiking, and traveling.

Cheryl Wang

Cheryl is an Associate Security Solutions Architect at AWS based in the SF Bay Area. Cheryl is passionate about cybersecurity and helping customers improve their security infrastructure. She holds a B.A. in Computer Science from Wellesley College. Outside of work, she enjoys writing and playing guzheng.

Building Multimodal AI Data Infrastructure with Pixeltable

Post Syndicated from Jeronimo De Leon original https://www.backblaze.com/blog/building-multimodal-ai-data-infrastructure-with-pixeltable/

A decorative image showing a chip with the word 'AI' and digital lines extending into the background.

We’re approaching a fascinating inflection point in AI development. Research from Epoch AI indicates that high-quality text data will be fully exhausted by 2026 to 2028. As recently as January, OpenAI co-founder Ilya Sutskever said at a conference that all the useful data online had already been used to train models. Over 35% of top websites now block AI scrapers. OpenAI is cutting deals with publishers like The Financial Times because freely available training data is running out.

So what comes next? Multimodal data: video, images, audio, sensor readings. Data that captures how the physical world actually operates, not just how we describe it in text.

Nvidia CEO Jensen Huang highlighted this shift when discussing Tesla’s AI advantage. He noted that the company has a “phenomenal position” because Tesla is collecting massive amounts of real-world data through its AI-enabled factories and autonomous vehicles.”

This real-world data, what some call “world data,” is multimodal at its core. It includes video from cameras capturing spatial relationships and motion, sensor telemetry recording physical interactions, images showing object states, and audio capturing environmental context. Video is particularly valuable because it captures temporal dynamics, depth perception, and how objects interact over time, insights that static text or images alone cannot provide.

Here’s the insight most organizations miss: you’re already generating this data.

Your organization is already producing multimodal data

Every single day, your organization produces massive amounts of multimodal data, including:

  • Zoom calls with video, audio, and screen shares
  • Security camera footage
  • Customer service interactions combining chat logs, voice recordings, website screen recordings and product images
  • Manufacturing sensors producing telemetry alongside quality inspection photos
  • Marketing teams creating videos, graphics, and campaign documents
  • Sales demos mixing presentations, product screenshots, and recorded conversations

And that’s just the short list.

The problem isn’t scarcity. It’s how multimodal data gets siloed, deleted, or stored in ways that make it unusable for AI applications. Video sits in one system and transcripts in another, with metadata scattered across databases. Most organizations treat this as operational exhaust rather than the strategic asset it represents.

Organizations that start systematically leveraging their multimodal data today will have capabilities tomorrow that generic models can never match.

The challenge: Multimodal infrastructure complexity

Building AI systems that work across images, video, audio, and text traditionally requires stitching together a fragmented technology stack. Videos live in object storage. Structured data sits in relational databases. Vector embeddings need specialized vector databases. Custom ETL pipelines handle transformations. Orchestration code coordinates everything. You need separate systems for caching, versioning, and lineage tracking.

This “data plumbing” consumes more engineering time than actual AI development. A straightforward workflow like building a searchable video archive with object detection and similarity search requires coordinating five or more systems and writing hundreds of lines of orchestration code.

The complexity creates a barrier that prevents most organizations from leveraging their multimodal data effectively, even when the underlying AI models are accessible through APIs. That’s the gap that Pixeltable solves.

How Pixeltable simplifies multimodal data workloads

Pixeltable replaces the fragmented multi-system architecture typically required for AI applications with a single declarative table interface. Instead of coordinating databases, file storage, vector databases, APIs, and orchestration tools separately, you work with tables where multimodal data lives alongside your transformations and AI operations.

The approach is straightforward. Store multimodal data in tables, define transformations as computed columns, and query everything together. Pixeltable handles the orchestration, caching, and model execution automatically.

Connect to data in-place 

Point Pixeltable at your existing object stores like AWS S3 or Backblaze B2 Cloud Storage without moving or duplicating data. Your files stay where they are, organized into queryable, versioned tables. No separate databases or vector stores needed.

Define workflows declaratively 

Transformations, model inference, and custom logic become Python computed columns. Extract frames from video, run object detection, generate embeddings, define it once and Pixeltable auto-orchestrates execution, manages dependencies, and handles incremental updates when new data arrives.

Query across everything

Leverage semantic search co-located with metadata. Raw data and AI-generated results in one interface. Build RAG systems with auto-synced embedding indexes that eliminate separate vector database management.

Focus on logic, not infrastructure

Full versioning for reproducibility. Automatic incremental processing means only necessary computations run when data changes. The same code works in development and production without rewrites.

For a practical example, explore our companion Github notebook Multimodal Data Processing with Pixeltable and Backblaze B2. It demonstrates how to extract and transform video frames using Pixeltable, then store the processed results in Backblaze B2 Cloud Storage with automatic URL generation.

Powering multimodal AI with Pixeltable and Backblaze B2

At Backblaze, we understand how essential multimodal data has become for AI development. Our collaboration with Pixeltable integrates B2 Cloud Storage directly into their open-source framework, giving organizations a simple and scalable foundation for managing complex AI workloads.

Pixeltable’s declarative design works seamlessly with Backblaze B2 across the entire AI data lifecycle. Whether you are processing video for model training, running inference on image streams, or building retrieval-augmented generation systems with multimodal embeddings, Backblaze B2 provides reliable S3 compatible storage that Pixeltable can reference directly without data duplication.

We are working closely with the Pixeltable team on a handful of initiatives to make multimodal workflows easier to deploy and scale. For those exploring this integration, we provide an example that demonstrates how Pixeltable and Backblaze B2 work together across the multimodal AI pipeline.

The data that fuels multimodal AI already exists across most organizations, from meeting recordings to customer interactions, video archives, and sensor logs. With Pixeltable and Backblaze B2, the infrastructure to harness that data effectively is now within reach.

Explore Pixeltable on GitHub or visit pixeltable.com to learn about declarative multimodal data infrastructure. For S3 compatible storage across your AI pipeline, check out Backblaze B2.

The post Building Multimodal AI Data Infrastructure with Pixeltable appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Racing karts on a Rust GPU kernel driver (Collabora blog)

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

In July, Collabora announced
the Rust-based Tyr
GPU driver
for Arm Mali
GPUs. Daniel Almeida has posted an update
on progress with a prototype of the driver running on a Rock 5B board
with the Rockchip RK3588 system-on-chip:

The Tyr prototype has progressed from basic GPU job execution to
running GNOME, Weston, and full-screen 3D games like SuperTuxKart,
demonstrating a functional, high-performance Rust driver that matches
C-driver performance and paves the way for eventual upstream
integration! […]

Tyr is not ready to be used as a daily-driver, and it will still
take time to replicate this upstream, although it is now clear that we
will surely get there. And as a mere prototype, it has a lot of
shortcuts that we would not have in an upstream version, even though
it can run on top of an unmodified (i.e., upstream) version of
Mesa.

That said, this prototype can serve as an experimental driver and
as a testbed for all the Rust abstraction work taking place
upstream. It will let us experiment with different design decisions
and gather data on what truly contributes to the project’s
objective.

There is also a video on
YouTube of the prototype in action.

[$] BPF and io_uring, two different ways

Post Syndicated from corbet original https://lwn.net/Articles/1046950/

BPF allows programs uploaded from user space to be run, safely, within the
kernel. The io_uring subsystem, too, can be thought of as a way of loading
programs in the kernel, though the programs in question are mostly a
sequence of I/O-related system calls. It has sometimes seemed inevitable
that io_uring would, like many other parts of the kernel, gain BPF
capabilities as a way of providing more flexibility to user space. That
has not yet happened, but there are currently two patches sets under
consideration that take different approaches to the problem.

Security updates for Thursday

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

Security updates have been issued by AlmaLinux (bind, bind9.18, container-tools:rhel8, expat, grub2, haproxy, idm:DL1, kernel, kernel-rt, lasso, libsoup, libssh, libtiff, pcs, podman, python-kdcproxy, qt5-qt3d, redis, redis:7, runc, shadow-utils, sqlite, squid, vim, webkit2gtk3, xorg-x11-server, xorg-x11-server-Xwayland, and zziplib), Debian (chromium), Oracle (lasso and postgresql), SUSE (erlang27, ghostscript, grub2, kernel, libIex-3_4-33, python312, and sbctl), and Ubuntu (linux, linux-aws, linux-aws-5.4, linux-gcp, linux-gcp-5.4, linux-hwe-5.4,
linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4,
linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp, linux-aws-6.8, linux-fips, linux-aws-fips, linux-gcp-fips, linux-oracle, and mysql-8.0, mysql-8.4).

Onboard at Cloud Speed with Rapid7 and AWS IAM Delegation

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/cds-onboard-at-cloud-speed-with-rapid7-aws-iam-delegation

Every great product experience starts with a smooth beginning. But in the world of cloud security, onboarding can sometimes feel like an obstacle course. Detailed fine-grained Identity and Access Management (IAM) configurations, lengthy deployment steps, and manual permission setups can turn what should be an exciting first impression into a tedious chore.

That’s changing. Rapid7 has enhanced the onboarding experience for Exposure Command and InsightCloudSec by integrating with AWS IAM temporary delegation – a new AWS capability that lets customers approve deployment access directly in the AWS console. The result? A faster, simpler, and more secure path to getting up and running in the cloud.

Why onboarding matters – and why it often fails  

The first minutes with a new platform matter. It’s the difference between “this is amazing” and “I’ll come back to it later.”

In cloud environments, setup usually involves multiple AWS services – compute, storage, networking, access management – all of which must be configured precisely to maintain security. Traditionally, customers have had to manually create IAM roles, adjust trust relationships, and fine-tune permissions just to let a partner solution like Rapid7 deploy resources.

It’s not just time-consuming; it’s error-prone. Misconfigured roles can cause deployment failures or unnecessary security risk. Support teams spend hours walking customers through the process, and the friction delays time-to-value. When scaling across dozens or hundreds of AWS accounts, those delays multiply fast.

Meet AWS IAM temporary delegation: What it is and why it matters

AWS IAM temporary delegation simplifies the entire setup journey. It allows trusted partners like Rapid7 to automate deployment securely – but only after the customer grants explicit, time-bound approval.

Here’s how it works: When you initiate onboarding from within Rapid7’s interface, you’re redirected to the AWS console. There, you can review the exact permissions Rapid7 is requesting and how long access will last. Once approved, AWS provides Rapid7 with temporary credentials to complete the setup. After the time window expires, that access ends automatically.

No long-term IAM keys, no manual role creation, and no guesswork. Customers stay in control, with full visibility and auditability. It’s automation with accountability built in.

How Rapid7 is putting this into action

With the latest release, Rapid7 has integrated this capability directly into Exposure Command and InsightCloudSec, creating a guided onboarding experience that happens almost entirely inside the Rapid7 interface.

Here’s the new flow:

  1. Customers configure deployment options in Rapid7’s InsightCloudSec environment.
  2. A temporary delegation request appears via an AWS console pop-up.
  3. An authorized AWS user reviews and approves the request.
  4. Rapid7 automatically deploys the necessary resources on the customer’s behalf.

This streamlined workflow eliminates dozens of manual steps and reduces onboarding time from hours to minutes. It’s faster, simpler, and still fully aligned with AWS’s strict security model. 

Speed, simplicity, and security

This integration hits the sweet spot between automation and trust:

  • Speed: Customers can start realizing value from Rapid7’s cloud security solutions in minutes instead of days.

  • Simplicity: The UI-driven process means no wrestling with IAM policies or JSON templates.

  • Security: Access is temporary and permission-scoped. Customers retain complete oversight through the AWS console and CloudTrail logs.

For organizations with compliance or security governance requirements, this is the ideal balance: operational efficiency without compromising control.

Beyond onboarding: What this says about Rapid7 and AWS alignment

This update isn’t just about faster onboarding. It’s a glimpse into Rapid7’s broader partnership with AWS. Rapid7 has long been an AWS Advanced Tier Partner, building integrations that help customers manage security across cloud-native environments. From leveraging AWS telemetry in MXDR to integrating with AWS services like CloudTrail and GuardDuty, Rapid7’s platform has been designed to meet customers where they already operate within AWS.

By adopting AWS IAM temporary delegation early, Rapid7 reinforces its commitment to cloud-first innovation and shared responsibility principles. Customers get the assurance that their onboarding, deployment, and operations all align with AWS security best practices. 

What this means for customers

If you’re deploying Rapid7 Exposure Command (Advanced or Ultimate) or InsightCloudSec on AWS, here’s what to expect:

  • A guided onboarding experience that automates AWS resource setup.
  • A faster, less error-prone workflow that still keeps you in control.
  • The ability for authorized users to approve temporary access requests directly in the AWS console.

Before onboarding, make sure someone in your organization has the permissions to approve delegation requests. After deployment, review your CloudTrail logs as part of normal governance;  you’ll see every action logged and time-bounded.

Value from day one

Onboarding shouldn’t be a hurdle. And now with AWS IAM Temporary Delegation and Rapid7’s enhanced experience, it no longer is. Together, AWS and Rapid7 have reimagined what “getting started” looks like in the cloud – faster, more intuitive, and just as secure as you need it to be.

It’s one more way Rapid7 is helping organizations unlock value from day one, while staying aligned with AWS’s best practices for identity, access, and automation.

See how easy secure onboarding can be.Explore Rapid7’s listings for Exposure Command and InsightCloudSec straight from the AWS Marketplace.

Scam USPS and E-Z Pass Texts and Websites

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/scam-usps-and-e-z-pass-texts-and-websites.html

Google has filed a complaint in court that details the scam:

In a complaint filed Wednesday, the tech giant accused “a cybercriminal group in China” of selling “phishing for dummies” kits. The kits help unsavvy fraudsters easily “execute a large-scale phishing campaign,” tricking hordes of unsuspecting people into “disclosing sensitive information like passwords, credit card numbers, or banking information, often by impersonating well-known brands, government agencies, or even people the victim knows.”

These branded “Lighthouse” kits offer two versions of software, depending on whether bad actors want to launch SMS and e-commerce scams. “Members may subscribe to weekly, monthly, seasonal, annual, or permanent licenses,” Google alleged. Kits include “hundreds of templates for fake websites, domain set-up tools for those fake websites, and other features designed to dupe victims into believing they are entering sensitive information on a legitimate website.”

Google’s filing said the scams often begin with a text claiming that a toll fee is overdue or a small fee must be paid to redeliver a package. Other times they appear as ads—­sometimes even Google ads, until Google detected and suspended accounts—­luring victims by mimicking popular brands. Anyone who clicks will be redirected to a website to input sensitive information; the sites often claim to accept payments from trusted wallets like Google Pay.

Сълзичка – паричка. Журналистическа етика за оплакване

Post Syndicated from Светла Енчева original https://www.toest.bg/sulzichka-parichka-zhurnalisticheska-etika-za-oplakvane/

Сълзичка – паричка. Журналистическа етика за оплакване

Преди близо 15 години се самоуби най-добрият ми приятел. Смъртта му предизвика медиен интерес – държавен служител, ерудит, с много последователи в Twitter, отнема живота си по особено мъчителен начин, ако използваме юридическото клише. Вестник „Труд“ публикува статия, която наред с хвалебствия за личността на починалия, с представянето на предположения като факти (включително в заглавието) и с фриволни интерпретации на туитове на различни хора и публикация от блога ми съдържаше скрупульозно описани детайли. Например с какво точно се е самоубил, конкретните стъпки на изпълнението – първо, второ, трето. Че по всяка вероятност е припаднал от болка.

Какъв е проблемът?

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

Така в една-единствена статия са нарушени няколко принципа от Етичния кодекс на българските медии, между които:

1.1.4 Ясно ще разграничаваме фактите от коментарите и предположенията.

2.6.4 Ще се въздържаме от възхваляващо или придаващо излишна сензационност отразяване на престъпления, насилие и жестокост.

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

Не изключение, а правило

Ще ми се да можех да кажа, че 15 години по-късно подобно отношение към правилата на професията може да се види само в жълто-кафявите медии (каквато „Труд“ не беше навремето), но уви. Нарушаването на стандартите на журналистическата етика в името на „по-сочни“ материали се среща толкова често, че човек остава с впечатлението, че то е нормата, не отклонението от нея. Че е окей да наричаш обвиняемия престъпник, да даваш да се разбере адресът на заподозрени или пострадали от престъпления – било като го казваш, било като показваш дома им. И т.н.

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

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

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

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

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

Безкритичност към институции и източници

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

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

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

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

Етични проблеми при отразяването на случаи с деца

Може да се приведат множество примери за нарушаването на журналистическата етика, но ще се спра конкретно върху темата за отразяването на случаи с деца, защото то се подчинява на строги стандарти за защита на неприкосновеността на личния им живот. Не само по силата на гилдийна саморегулация, а и на Закона за закрила на детето. А той постановява, че не могат да се разгласяват сведения и данни за дете без съгласието на родителите или на законните му представители. Както и на самото дете, ако е навършило 14 години, а ако става въпрос за съдебно производство – 10 години.

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

Законът беше нарушен с лека ръка наскоро,

когато 16-годишният син на евродепутата и бивш председател на ДСБ Радан Кънев беше арестуван заради притежание на марихуана в минимално количество. МВР разпространи прессъобщение, в което разкри самоличността на детето. Асоциацията на европейските журналисти – България посочи, че в случая Вътрешното министерство нарушава не само българското законодателство, а и Конвенцията на ООН за правата на детето. И все пак случаят беше широко отразен – заедно с личните данни – дори от медии с претенцията да отстояват висок професионализъм.

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

На ръба на журналистическата етика

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

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

„Отговорните представители на медиите трябва да съзнават, че възрастните невинаги са наясно кой е най-добрият интерес на детето“, се казва в пътеводителя на УНИЦЕФ за етично отразяване на децата в медиите.

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

Етически смущаващи са и някои реплики на директорката на психиатрията в Нови Искър Цветеслава Гълъбова. От висотата на професионалната си позиция тя отправя квалификации и свежда проблема със сексуалното насилие до остарялото понятие за моминска чест:

Как ще обясним на това момиче, когато порасне след години, че то няма онова, което се нарича девическа чест, и не е отнето при любовен акт с любим човек, а от една извратена лелка?

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

Звучи ужасно, но не, не бих чакала правосъдието.

От другата страна на сълзичката

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

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

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

The collective thoughts of the interwebz