Post Syndicated from xkcd.com original https://xkcd.com/3171/

Post Syndicated from xkcd.com original https://xkcd.com/3171/

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:
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.
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.
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/shorts/hsvXdMWvKG0
Post Syndicated from The Hook Up original https://www.youtube.com/watch?v=kMLB4HVTp8I
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.
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
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.
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
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.
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 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
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.
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.
Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/5T2clCWmo24
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.
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:
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.
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:
Finance datasets or join assets consistently tagged with the same glossary termIn 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.
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.
Complete the following steps to create a new glossary and add terms:



Finance in the Business Unit Details glossary.
Complete the following steps to create a rule to define glossary terms:


Finance project to have the Finance tag for all assets published to the catalog.

Complete the following steps to publish your asset with the enforced rules:
financial_analysis project page, go to your asset.
Finance term should be assigned.


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

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.
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.
SageMaker Catalog now offers the following key capabilities:
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.”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:
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.
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.
Complete the following steps to create a new metadata form:


Domain, Business Owner, and Approved Use Case.

Complete the following steps to attach the metadata form to a column:
business_finance).
revenue field.



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:
revenue field where you added the metadata form.


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.

Consider the following best practices when using this feature:
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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:
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. |
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.
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.
The following code snippet illustrates this configuration implemented with the AWS CDK.
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.
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:
You can also retrieve tenant-specific logs across all log streams:
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.
When using the new tenant isolation for Lambda functions, consider the following:
When using the new tenant isolation mode for Lambda functions, AWS recommends the following best practices:
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.
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.
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.
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:
For this walkthrough, you must have the following resources ready to use:
PutObject, PutObjectACL, GetBucketACL and GetBucketLocation (see the following example bucket policy)2. AWS Command Line Interface (AWS CLI) configured
With the prerequisites in place, you’re ready to deploy the first solution.
To enable CRL distribution:
Figure 1: Edit the revocation configuration
Figure 2: Enter a name for your CRL
To create an SNS topic and Lambda function:
Figure 3: Create an SNS topic
Figure 4: Create a Lambda function
Example code (Python 3.13):
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:
Figure 5: Configure the event pattern
Figure 6: Select the Lambda function as the target
To test the success of the Lambda function:
openssl x509 -in cert.pem -noout -serial aws acm-pca revoke-certificate —certificate-authority-arn <CA ARN> \ —certificate-serial <SERIAL NUMBER RETURNED IN STEP 1> --revocation-reason “UNSPECIFIED” RevokeCertificate was called, then monitor the CloudWatch log of the Lambda function. You should also get a notification message from your SNS topic.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:
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.
For this walkthrough, you must have the following resources available:
With the prerequisites in place, you’re ready to use the console and AWS CLI to deploy the solution.
To deploy the solution:
Figure 7: Create 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
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:
Figure 10: Gateway VPC endpoint configuration
Figure 11: Private route table configuration
Figure 12: VPC private instance configuration
Figure 13: S3 bucket policy
The following is an example S3 bucket policy for private CA CRL access with VPC endpoint restrictions:
Figure 14: S3 bucket CRL properties
Create a private hosted zone:
Create a record set:
Figure 15: Hosted zone details
Verify configuration:
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:
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
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.
Post Syndicated from Talks at Google original https://www.youtube.com/watch?v=t8q43fsioqU
Post Syndicated from Jeronimo De Leon original https://www.backblaze.com/blog/building-multimodal-ai-data-infrastructure-with-pixeltable/

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.
Every single day, your organization produces massive amounts of multimodal data, including:
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.
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.
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.
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.
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.
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.
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.
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
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.
Post Syndicated from The Hook Up original https://www.youtube.com/watch?v=Z9KQ2fDDTOA
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.
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).
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.
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.
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.
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:
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.
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.
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.
If you’re deploying Rapid7 Exposure Command (Advanced or Ultimate) or InsightCloudSec on AWS, here’s what to expect:
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.
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.
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 The Atlantic original https://www.youtube.com/watch?v=m36DClaC5bY
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-годишно момиченце в детска градина в гр. Каблешково. Не поставям под въпрос значимостта му – чак след него случаят придобива гласност и институциите се виждат принудени да се задействат.
За тази гласност обаче пострадалото дете и семейството му плащат висока цена. Смелостта на родителите да излязат от анонимност и да застанат пред камерата с имената и лицата си води дотам, че детето много лесно може да бъде разпознато, макар името му да не се споменава и лицето му да не се вижда ясно. А историята ще продължава да живее в интернет – и когато момичето порасне.
„Отговорните представители на медиите трябва да съзнават, че възрастните невинаги са наясно кой е най-добрият интерес на детето“, се казва в пътеводителя на УНИЦЕФ за етично отразяване на децата в медиите.
В опита си да постигне ефект материалът нарушава някои от принципите на Етичния кодекс на българските медии – например че журналистите не бива да засилват мъката на пострадалите от престъпление. А Ивайлова прилага принципа „сълзичка – паричка“ – задава на бащата въпроса дали често плаче, като в същото време камерата снима насълзените му очи в близък план. И го пита във връзка със съдебномедицинската експертиза, констатираща разкъсан химен на детето: „Какво е за един баща да види такъв документ от гинеколог?“.
Етически смущаващи са и някои реплики на директорката на психиатрията в Нови Искър Цветеслава Гълъбова. От висотата на професионалната си позиция тя отправя квалификации и свежда проблема със сексуалното насилие до остарялото понятие за моминска чест:
Как ще обясним на това момиче, когато порасне след години, че то няма онова, което се нарича девическа чест, и не е отнето при любовен акт с любим човек, а от една извратена лелка?
По-сериозният проблем е, че ръководителката на голяма психиатрична болница призовава към саморазправа, след като Ивайлова я приканва да излезе от професионалната си роля, заради която я е поканила. На въпроса как би реагирала, ако внукът ѝ преживее сексуално насилие, тя отговаря:
Звучи ужасно, но не, не бих чакала правосъдието.
Освен да носи рейтинг, кликове и парички, вторачването в човешката мъка изпълнява и друга функция – отмества обществения поглед от темата за отговорността. Сълзите на хората са и по-безопасни за медиите от задаването на въпроси за невзети мерки, допуснати грешки, сбъркани приоритети. Не че в някои случаи няма и сълзи, и въпроси.
По същия начин легитимният гняв на хората, често намиращ израз в желание за по-строги наказания, отвлича вниманието от неработещото правосъдие, липсата на превенция, корупцията, безразличието. В резултат се приемат закони за повече години затвор и по-високи глоби, които са все така неработещи.
Сълзите затрогват, когато ги гледаме. Но когато излизат от нашите очи, а болката ни се експлоатира в името на рейтинга, кликовете и печалбата, никак не е трогателно. Чувството е на гняв, безпомощност, унижение – едновременно. Не пожелавам на журналистите, прилагащи принципа „сълзичка – паричка“, да изпитат на гърба си преживяванията на някои от героите на репортажите си, нито това, което ми беше след прочитането на статията на „Труд“, с която започнах. Малко емпатия обаче би била от полза. Не сълзлива, а с уважение.