There are two types of companies in the world: those that are afraid of becoming the next Colonial Pipeline poster child for security issues, and those that are at risk of doing just that.
Quelle: Mirantis
The distribution agreement across Asia-Pacific will help partners ship code faster on private and public clouds CAMPBELL, Calif., August 24, 2021 — Mirantis, the open cloud company, today announced it has partnered with Westcon-Comstor, a value-added technology distributor of category-leading solutions in data center, infrastructure, collaboration and security, for a distribution agreement across Asia-Pacific that … Continued
Quelle: Mirantis
Recently, Bryan Langston, Senior Solutions Engineer at Mirantis, presented at MediaOps’ virtual event Cloud Native Days, highlighting the latest cyber attacks and explaining best practices for protecting your organization from these types of attacks through the use of image registries. Below you will find the recording as well as a transcript to help you follow … Continued
Quelle: Mirantis
Whether you are a social media site, security company, or enterprise email manager, keeping users safe is always the goal. However, the top two threats to users’ security, phishing and malware, can make that challenging. The Safe Browsing teamat Google has been dedicated to defending the web from malware, phishing, and more threats for more than a decade. Google scans more than a billion links on a daily basis to produce a list of over one million malicious URLs related to phishing, social engineering, malware, and unwanted software.Over the last couple years, we’ve introduced an enterprise-ready tool that builds on the technology used in Safe Browsing and adds new features to make the Web Risk API. Web Risk API enables any enterprise to have access to Google’s phishing and malware data to confirm if a URL is malicious. Today, we are going to share with you our best practices for how to use all of Web Risk APIs together to protect your business from web-based attacks. How Web Risk API WorksUsers can submit a URL to the Web Risk API to see if it is safe or unsafe. The URLs that Web Risk can assess can be submitted from any platform or device in your company that connects to the internet. A few common sources for potentially malicious URLs are: User Generated Content: For large social media sites, it’s common for attackers to directly post or social engineer other users to share viral malicious links. Emails: Internally or externally sourced emails are the primary entry vector for spreading phishing and malwareUser Reports: Enterprises will often have a pishing@yourcompany.com reporting address or form to enable users to report phishing either sent from your infrastructure or attempting to present using your brand identity (logos, messaging, login details)Enterprise user activity observed via a firewall or CASBReferral Links: Attackers often link directly to a real customer site to source content/images. Looking at traffic to these resources can often expose this type of early fraud.Once you have the results back from the Web Risk API, your security team or automated system will be able to quickly take action to block the content and run remedial analysis to understand any action a compromised user may have taken. If a user is compromised by phishing, their account should be reset and the user notified that any data in the account has been exposed. If a user is compromised by malware, the user’s device and software will often need to be reset to ensure the malware has been fully removed. Additionally, any user accounts accessed since the time of the malware compromise should be considered at risk. How Web Risk API’s 4 APIs WorkDue to the variety of fraudulent URLs, Web Risk provides you with a few different URLs to help you detect spam and abuse.Lookup API: Submit a URL and see if the URL is good or bad.Update API: Store a list of partial hashes of malicious URLs. We recommend you do a local comparison and send any matches to the Web Risk API which will return a full hash. This method requires more implementation than the Lookup API, but primarily uses calls to a local database and does not require transmission of a full URL.Evaluate API : Submit a URL and receive a risk type and confidence score assessment. While the Update and Lookup APIs are a result of confirmed malicious behavior, the Evaluate API relies on the URL’s reputation. This has the advantages of not requiring a crawl of the URL and also it is not as vulnerable to URL spoofing or cloaking. Submissions API: Enables companies to submit URLs directly to the Safe Browsing blocklist. Any URLs found to be on the violating policy list will be added to the Safe Browsing blocklist, which is consumed by more than 4 Billion devices worldwide (including many non-Google platforms). This broad scope enables us to help defend customers from virtual phishing, brand impersonation phishing, and other types of user attacks that are being distributed outside the control of a company’s own infrastructure.How to Use All the Web Risk APIs Together To Protect Your End UsersWe recommend that these URLs be used together and as follows: An initial call to the Update API can be made to determine if a URL is known to be malicious . This is the best first call due to the speed of response (local hash comparison). If the Update API doesn’t return a malicious verdict, the next call can be made to the Evaluate API (server call) to determine if the URL contains any other signals of risk.Finally, if you would like Google to crawl the URL or know the URL to be bad, you can submit to the Submissions API. This API will do a full crawl of the URL and add it to the Safe Browsing Blocklist if found to be malicious.These calls can be made in this prescribed order or parallel. Also, if you have an internal risk model or analyst team you can combine these signals as input to your own detection models.Once a malicious URL has been found, the action that you need to take depends on the channel the URL exists in.Emails: Block access via web proxy, log to SIEM, follow up on exposed users/devicesUser Reports: Submit URL to Safe Browsing, block malicious link on all company control platformsUser Generated Content: Remove link from user-facing content. Investigate the user who posted. Note – many users propagate malicious content unknowingly. Enterprise user activity observed via a firewall or CASB: Block access via web proxy, log to SIEM, follow up on exposed users/devicesReferral Links: Attackers often link directly to a real customer site to source content/images. Submit URL to Safe Browsing, block malicious link on all company control platformsDefending against phishing and malware to prevent account compromise is a never ending battle. The Web Risk API team is dedicated to providing tools to keep your users safe. To get started with Web Risk API, contact our sales team.Related ArticleRegistration is open for Google Cloud Next: October 12–14Register now for Google Cloud Next on October 12–14, 2021Read Article
Quelle: Google Cloud Platform
Google Cloud Functions provides a simple and intuitive developer experience to execute code from Google Cloud, Firebase, Google Assistant, or any web, mobile, or backend application. Oftentimes that code needs secrets—like API keys, passwords, or certificates—to authenticate to or invoke upstream APIs and services.While Google Secret Manager is a fully-managed, secure, and convenient storage system for such secrets, developers have historically leveraged environment variables or the filesystem for managing secrets in Cloud Functions. This was largely because integrating with Secret Manager required developers to write custom code… until now. We listened to customer feedback and today we are announcing Cloud Functions has a native integration with Secret Manager!This native integration has many key benefits including:Zero required code changes. Cloud functions that already consume secrets via environment variables or files bundled with the source upload simply require an additional flag during deployment. The Cloud Functions service resolves and injects the secrets at runtime and the plaintext values are only visible inside the process.Easy environment separation. It’s easy to use the same codebase across multiple environments, e.g., dev, staging, and prod, because the secrets are decoupled from the code and are resolved at runtime.Supports the 12-factor app pattern. Because secrets can be injected into environment variables at runtime, the native integration supports the 12-factor pattern while providing stronger security guarantees.Centralized secret storage, access, and auditing. Leveraging Secret Manager as the centralized secrets management solution enables easy management of access controls, auditing, and access logs.Cloud Functions’ native integration with Secret Manager is available in preview to all Google Cloud customers today. Let’s take a deeper dive into this new integration.ExampleSuppose the following cloud function invoked via HTTP uses a secret token to invoke an upstream API:Without Cloud Functions’ native integration with Secret Manager, this function is deployed via:This approach has a number of drawbacks, the biggest of which being that anyone with viewer permissions on the Google Cloud project can see the environment variables set on a cloud function.To improve the security of this code, migrate the secret to Secret Manager in the same project:Finally, without changing any code in the function re-deploy with slightly different flags:It’s truly that easy to migrate from hard-coded secrets to using secure secret storage with Secret Manager! To add even more layers of security, consider running each cloud function with a dedicated service account and practice the principle of least privilege. Learn more in the Secret Manager Best Practices guide.Making security easySecurity and proper secrets management are core pillars of modern software development, and we’re excited to provide customers a way to improve the security of their cloud functions. To learn more about the new native integration, check out the Cloud Functions documentation. You can also learn more about Cloud Functions or learn more about Secret Manager.Related Article4 new features to secure your Cloud Run servicesWe’re improving the security of your Cloud Run environment with things like support for Secret Manager and Binary Authorization.Read Article
Quelle: Google Cloud Platform
Picking the right database for your application is not easy. The choice depends heavily on your use case—transactional processing, analytical processing, in-memory database, and so on—but it also depends on other factors. This post covers the different database options available within Google Cloud across relational (SQL) and non-relational (NoSQL) databases and explains which use cases are best suited for each database option. Click to enlargeRelational databases In relational databases information is stored in tables, rows and columns, which typically works best for structured data. As a result they are used for applications in which the structure of the data does not change often. SQL (Structured Query Language) is used when interacting with most relational databases. They offer ACID consistency mode for the data, which means:Atomic: All operations in a transaction succeed or the operation is rolled back.Consistent: On the completion of a transaction, the database is structurally sound.Isolated: Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.Durable: The results of applying a transaction are permanent, even in the presence of failures.Because of these properties, relational databases are used in applications that require high accuracy and for transactional queries such as financial and retail transactions. For example: In banking when a customer makes a funds transfer request, you want to make sure the transaction is possible and it actually happens on the most up-to-date account balance, in this case an error or resubmit request is likely fine.There are three relational database options in Google Cloud: Cloud SQL, Cloud Spanner, and Bare Metal Solution.Cloud SQL: Provides managed MySQL, PostgreSQL and SQL Server databases on Google Cloud. It reduces maintenance cost and automates database provisioning, storage capacity management, back ups, and out-of-the-box high availability and disaster recovery/failover. For these reasons it is best for general-purpose web frameworks, CRM, ERP, SaaS and e-commerce applications.Cloud Spanner: Cloud Spanner is an enterprise-grade, globally-distributed, and strongly-consistent database that offers up to 99.999% availability, built specifically to combine the benefits of relational database structure with non-relational horizontal scale. It is a unique database that combines ACID transactions, SQL queries, and relational structure with the scalability that you typically associate with non-relational or NoSQL databases. As a result, Spanner is best used for applications such as gaming, payment solutions, global financial ledgers, retail banking and inventory management that require ability to scale limitlessly with strong-consistency and high-availability. Bare Metal Solution: Provides hardware to run specialized workloads with low latency on Google Cloud. This is specifically useful if there is an Oracle database that you want to lift and shift into Google Cloud. This enables data center retirements and paves a path to modernize legacy applications. Non-relational databasesNon-relational databases (or NoSQL databases) store compex, unstructured data in a non-tabular form such as documents. Non-relational databases are often used when large quantities of complex and diverse data need to be organized. Unlike relational databases, they perform faster because a query doesn’t have to access several tables to deliver an answer, making them ideal for storing data that may change frequently or for applications that handle many different kinds of data. For example, an apparel store might have a database in which shirts have their own document containing all of their information, including size, brand, and color with room for adding more parameters later such as sleeve size, collars, and so on.Qualities that make NoSQL databases fast:Eventual consistency: stores usually exhibit consistency at some later point (e.g., lazily at read time)Horizontal scaling, usually using hashed distributionsTypically, they are optimized for a specific workload pattern (i.e., key-value, graph, wide-column)Typically, they don’t support cross shard transactions or flexible isolation modes.Because of these properties, non-relational databases are used in applications that require large scale, reliability, availability, and frequent data changes.They can easily scale horizontally by adding more servers, unlike some relational databases, which scale vertically by increasing the machine size as the data grows. Although, some relations databases such as Cloud Spanner support scale-out and strict consistency.Non-relational databases can store a variety of unstructured data such as documents, key-value, graphs, wide columns, and more. Here are your non-relational database options in Google Cloud: Document databases: Store information as documents (in formats such as JSON and XML). For example: FirestoreKey-value stores: Group associated data in collections with records that are identified with unique keys for easy retrieval. Key-value stores have just enough structure to mirror the value of relational databases while still preserving the benefits of NoSQL. For example: Datastore, Bigtable, MemorystoreIn-memory database: Purpose-built database that relies primarily on memory for data storage. These are designed to attain minimal response time by eliminating the need to access disks. They are ideal for applications that require microsecond response times and can have large spikes in traffic. For example: MemorystoreWide-column databases: Use the tabular format but allow a wide variance in how data is named and formatted in each row, even in the same table. They have some basic structure while preserving a lot of flexibility. For example: BigtableGraph databases: Use graph structures to define the relationships between stored data points; useful for identifying patterns in unstructured and semi-structured information. For example: JanusGraphThere are three non-relational databases in Google Cloud:Firestore: Is a serverless document database which scales on demand and acts as a backend-as-a-service. It is DBaaS that increases the speed of building applications. It is perfect for all general purpose uses cases such as ecommerce, gaming, IoT and real time dashboards. With Firestore users can interact with and collaborate on live and offline data making it great for real-time application and mobile apps. Cloud Bigtable: Cloud Bigtable is a sparsely populated table that can scale to billions of rows and thousands of columns, enabling you to store terabytes or even petabytes of data. It is ideal for storing very large amounts of single-keyed data with very low latency. It supports high read and write throughput at sub-millisecond latency, and it is an ideal data source for MapReduce operations. It also supports the open-source HBase API standard to easily integrate with the Apache ecosystem including HBase, Beam, Hadoop and Spark along with Google Cloud ecosystem.Memorystore: Memorystore is a fully managed in-memory data store service for Redis and Memcached at Google Cloud. It is best for in-memory and transient data stores and automates the complex tasks of provisioning, replication, failover, and patching so you can spend more time coding. Because it offers extremely low latency and high performance, Memorystore is great for web and mobile, gaming, leaderboard, social, chat, and news feed applications.ConclusionChoosing a relational or a non-relational database largely depends on the use case. Broadly, if your application requires ACID transactions and your data structure is not going to change much, select a relational database. In Google Cloud use Cloud SQL for any general-purpose SQL database and Cloud Spanner for large-scale globally scalable, strongly consistent use cases. In general, if your data structure may change later and if scale and availability is a bigger requirement than consistency then a non-relational database is a preferable choice. Google Cloud offers Firestore, Memorystore, and Cloud Bigtable to support a variety of use cases across the document, key-value, and wide column database spectrum.For more comparison resources on each database check out the overview. For more hands-on experience with Bigtable, check out our on-demand training here and learn about migrating databases to managed services check out this whitepaper. For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev.Related ArticleWhat is Cloud Spanner?Want a relational database that scales globally? Learn all about Cloud Spanner.Read Article
Quelle: Google Cloud Platform
AWS Lambda unterstützt jetzt Python 3.9 sowohl als verwaltete Laufzeit als auch als Container-Basis-Image. Sie können jetzt AWS Lambda-Funktionen in Python 3.9 verfassen und die neuen Funktionen nutzen, z. B. Unterstützung für TLS 1.3, neue String- und Wörterbuchoperationen und verbesserte Zeitzonenunterstützung. Python 3.9 enthält auch Leistungsoptimierungen, von denen Sie profitieren können, ohne Codeänderungen vorzunehmen. Weitere Informationen zur Lambda-Unterstützung für Python 3.9 finden Sie in unserem Blogbeitrag zur Python 3.9-Laufzeit, die jetzt in AWS Lambda verfügbar ist.
Quelle: aws.amazon.com
AWS Elastic Beanstalk unterstützt jetzt Capacity Rebalancing für Amazon-EC2-Auto-Scaling-Gruppen (ASG). Diese Funktion reduziert Spot-Instance-Unterbrechungen für die Anwendungen der Kunden. Wenn aktiviert, versucht ASG Capacity Rebalancing automatisch, Spot-Instances in einer Auto-Scaling-Gruppe zu ersetzen, bevor sie unterbrochen werden.
Quelle: aws.amazon.com
AWS Systems Manager Fleet Manager, eine Funktion in AWS Systems Manager (SSM), die Sie bei der Rationalisierung und Skalierung Ihrer Remote-Server-Verwaltungsprozesse unterstützt, bietet jetzt die Möglichkeit, auf einen Blick Berichte über Ihre SSM verwaltete Instances zu erstellen. Die neue Funktion ermöglicht es Ihnen, das Fleet Manager-Informationspanel anzupassen, in dem Sie Warnungen, Status und Details der verwalteten Instances anzeigen und zur lokalen Anzeige und Analyse downloaden können.
Quelle: aws.amazon.com
AWS IoT Device SDK für Embedded C (C-SDK) Version 202108.00 enthält die AWS SigV4-Bibliothek und eine überarbeitete AWS IoT Flottenbereitstellungs-Client-Bibliothek für IoT-Anwendungen. Diese Version erleichtert Entwicklern, die C-SDK verwenden, die Authentifizierung eingehender API-Anforderungen an AWS-Services von IoT-Geräten, auf denen HTTP läuft, und die Bereitstellung von IoT-Geräten, die nicht über eindeutige Zertifikate verfügen.
Quelle: aws.amazon.com
