{"id":6619,"date":"2025-01-16T06:28:14","date_gmt":"2025-01-16T05:28:14","guid":{"rendered":"https:\/\/andreas-wolter.com\/?p=6619"},"modified":"2026-04-16T19:01:02","modified_gmt":"2026-04-17T00:01:02","slug":"protecting-database-data-at-rest-tde-backupencryption-alwaysencrypted","status":"publish","type":"post","link":"https:\/\/andreas-wolter.com\/en\/protecting-database-data-at-rest-tde-backupencryption-alwaysencrypted\/","title":{"rendered":"Protecting database data at rest: Transparent Data Encryption, Backup Encryption or Always Encrypted"},"content":{"rendered":"\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-m0cxh8ps-6f194c3ca2e988fb05fe259438dfed13\">\n#top .av-special-heading.av-m0cxh8ps-6f194c3ca2e988fb05fe259438dfed13{\npadding-bottom:10px;\n}\nbody .av-special-heading.av-m0cxh8ps-6f194c3ca2e988fb05fe259438dfed13 .av-special-heading-tag .heading-char{\nfont-size:25px;\n}\n.av-special-heading.av-m0cxh8ps-6f194c3ca2e988fb05fe259438dfed13 .av-subheading{\nfont-size:15px;\n}\n<\/style>\n<div  class='av-special-heading av-m0cxh8ps-6f194c3ca2e988fb05fe259438dfed13 av-special-heading-h3 blockquote modern-quote  avia-builder-el-0  el_before_av_textblock  avia-builder-el-first '><h3 class='av-special-heading-tag'  itemprop=\"headline\"  >Protecting database data at rest: Transparent Data Encryption, Backup Encryption or Always Encrypted<\/h3><div class=\"special-heading-border\"><div class=\"special-heading-inner-border\"><\/div><\/div><\/div>\r\n\r\n<section  class='av_textblock_section av-m0cxgkjy-c935304b4106b45214698f40e83a9894 '   itemscope=\"itemscope\" itemtype=\"https:\/\/schema.org\/BlogPosting\" itemprop=\"blogPost\" ><div class='avia_textblock'  itemprop=\"text\" ><p>Recently I wrote about <strong>protecting data in transit<\/strong> by using TLS for encryption (<a href=\"https:\/\/andreas-wolter.com\/en\/tls-trusted-certificates-encrypt-data-transit-sqlservers\/\">Use TLS 1.2 and trusted certificates to encrypt data in transit for all SQL Servers, including development environments<\/a> )<\/p>\n<p>This article is about how to <strong>protect data at rest<\/strong>.<\/p>\n<h1>First: Where does data reside when talking about SQL Server?<\/h1>\n<p>Before deciding on a technology, one should understand where the data resides which we want to protect.<\/p>\n<p>When it comes to data in Microsoft SQL Server, not everything is as obvious as it seems from afar. While it may be clear that table data is stored within the data file, there are numerous other places where data can be exposed in clear text. And we do not want to overlook any of these spots.<\/p>\n<p>Therefore, let\u2019s have a look at all the places where the SQL Engin itself may expose data:<\/p>\n<p>(Note: I am not including the applications here. Those need to be considered on a case-by-case basis. But I am giving some pointers to what else to consider.)<\/p>\n<ul>\n<li>Inside the <strong>data files (mdf, ndf)<\/strong> (no surprise here)<\/li>\n<li>In addition to the data files, data is also visible through the <strong>transaction log (.ldf)<\/strong> of the respective database.<\/li>\n<li>Also, the shared <strong>TempDB<\/strong> system database can contain user data.<\/li>\n<li>Databases may contain <strong>files<\/strong>: Either they use the <strong>Filestream<\/strong> functionality of SQL Server (recommended), or they may use just text links inside a data table and store the files in a <strong>custom location on disk<\/strong>.<\/li>\n<\/ul>\n<p>This can be anywhere and is completely out of the hands of SQL Server: It can be on the SQL Server but also on a file server, or even on the client itself (permanently or temporary).<\/p>\n<ul>\n<li><strong>In-Memory OLTP data<\/strong> which is stored in the MEMORY_OPTIMIZED_DATA filegroup<\/li>\n<li>If you are using replication, you need to consider not only the subscribers but also the snapshot data stored in <strong>files on disk<\/strong>.<\/li>\n<li>Finally: <strong>Backups<\/strong>. Backups are (hopefully) stored on a different storage system than the active database system, usually at some centralized backup storage solution.\n<ol>\n<li>Make sure to account for native SQL backups, as well as for backups that may be created by a storage virtualization layer, or <strong>third-party backup software<\/strong>, by taking <strong>snapshots<\/strong> of the whole volumes or individual files.<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<p>As we can see, depending on the application and the SQL Server architecture, some data is exposed outside of the regular database files. Let\u2019s keep that in mind for the next step.<\/p>\n<h1>What to protect against<\/h1>\n<p>Now you probably would like to say: encrypt everything. But let\u2019s spend a few thoughts on the <strong>attack vector<\/strong> that we want to prevent \u2013 in the context of the mentioned targets above:<\/p>\n<p>If you look through the list above, it is mainly about 2 targets that exist in every system:<\/p>\n<ul>\n<li>the <strong>local storage<\/strong> of the machine with the database engine running (in this context I would consider the volumes provided by a SAN \u201clocal\u201d as well)<\/li>\n<li>the <strong>backup storage<\/strong><\/li>\n<\/ul>\n<p>If an attacker gains access to the local storage of SQL Server, there are two sub-scenarios that are likely:<\/p>\n<ul>\n<li>SQL Server is compromised and with that: <strong>all data that SQL Server has access to<\/strong><\/li>\n<li>The whole system (the Windows server as such) is compromised: <strong>any file<\/strong> can be accessed and stolen. &#8211; This is the most common case.<\/li>\n<\/ul>\n<p><em>Note<\/em><br \/>\nWhat is <strong>not<\/strong> a plausible scenario is that the attacker can only access specific database files (data files for a specific database but no other database files). I am mentioning this apparently irrelevant difference because we need to consider it when we choose the proper technology.<br \/>\nI am also excluding the \u201cattacker walks out of the data center with the whole server under the arm\u201d here. Statistically, this is very unlikely (mostly in these cases it\u2019s then even about the hardware rather than the data on the servers). But for data centers containing highly valuable assets, BitLocker or similar is a must to protect against this possibility.<\/p>\n<h1>Goal<\/h1>\n<p>We must ensure that we can encrypt data at rest in a manner that prevents attackers from accessing the data &#8211; even if the SQL Server files or the entire machine are compromised. (and this last bit is important as we shall see)<\/p>\n<p>When it comes to encryption, two factors mainly determine its strength: the obvious one is the <strong>encryption algorithm<\/strong>. (AES, RSA, etc.) But there is a second factor to keep in mind: the security of the <strong>encryption key<\/strong>. Without that key, the data is useless to anyone. Therefore, this key must be stored in a secure location but easily accessible enough to allow required operations on the encrypted data.<\/p>\n<h1>The choice: TDE, Backup encryption or Always Encrypted.<\/h1>\n<p>SQL Server offers several technologies for encrypting data at rest:<\/p>\n<ul>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/security\/encryption\/transparent-data-encryption?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Transparent data encryption (TDE)<\/a> \u2013 encrypts the database files on disk but decrypts the data on the fly when read by the SQL Server engine, thus being completely \u201ctransparent\u201d to queries.<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/backup-restore\/backup-encryption?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Backup encryption<\/a> \u2013 encrypts the backup files as part of the BACKUP DATABASE command<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/security\/encryption\/always-encrypted-database-engine?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Always Encrypted<\/a> \u2013 encrypts data in columns, initiated through the client application\u2019s driver. SQL Server never sees the unencrypted data.<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/security\/encryption\/always-encrypted-enclaves?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Always Encrypted with secure enclaves<\/a> \u2013 same as (3) but by using a secure enclave in the server\u2019s memory supports many more operations on the encrypted data than the initial version without secure enclaves.<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/t-sql\/functions\/cryptographic-functions-transact-sql?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Cryptographic functions (ENCRYPTBYKEY, ENCRYPTBYPASSPHRASE, ENCRYPTBYASYMKEY, ENCRYPTBYCERT)<\/a> &#8211; a programmatic way, using T-SQL and certificates or keys which are stored in SQL Server, or passwords, to encrypt values in table cells. All of these options have their drawbacks, and I would recommend using Always Encrypted over these functions.<\/li>\n<\/ul>\n<p>If you are not familiar with these technologies, please follow the links provided to learn more about their functionality since I will not go into all aspects in this article.<\/p>\n<p>For the sake of this article, the difference between (3) Always Encrypted and (4) Always Encrypted with secure enclaves is irrelevant: both encrypt the data stored in tables. There are differences in supported operations, and you should opt for Always Encrypted <u>with secure enclaves<\/u> if your application and SQL Server versions support it.<\/p>\n<p>Cryptographic functions (5) are a programmatic way, using T-SQL and certificates or keys which are stored in SQL Server, or passwords, to encrypt values in table cells. All of these options have their drawbacks, and I would recommend using Always Encrypted over these functions.<\/p>\n<p>This article will center on TDE, backup encryption, and Always Encrypted for protecting data at rest.<\/p>\n<p>Let\u2019s start with TDE:<\/p>\n<h2>TDE<\/h2>\n<p>When encryption for SQL Server is discussed, the immediate suggestion is often to \u201cuse TDE (Transparent Data Encryption).\u201d And in some environments which require <em>double encryption<\/em> to be used, the recommendation might be: \u201cuse TDE on top of Bitlocker\u201d.<br \/>\nSince TDE is comparatively easy to turn on (turned off not so much), there is rarely any push-back.<\/p>\n<p>However, there are 2 downsides to TDE which I want to point out here:<\/p>\n<ol>\n<li>Once TDE is turned on for one database, the shared system database <strong>TempDB will automatically be encrypted by SQL Server<\/strong> as well. This is of course necessary for security, but it needs to be considered from a performance perspective in addition to the encryption of the user database. (TDE incurs a CPU performance overhead of about 2% to 4%.) Although the impact is minor, it is non-negligible, particularly since it affects all databases, regardless of TDE usage. And CPU is the ultimate and non-adjustable resource.<br \/>\nOn top of that, <strong>this operation is irreversible<\/strong>: while you can turn off encryption of every user database, <strong>for TempDB there is no way to turn TDE off ever again<\/strong>. So, if you play with TDE for the first time make sure to not use your production system, as even if you remove TDE from your database, TempDB will remain encrypted forever.<\/li>\n<li>Security: contrary to common belief, <strong>TDE does NOT protect when the Windows server that hosts SQL Server has been compromised<\/strong>: if the attacker gains access to the system database master in addition to the user database, he will be able to decrypt the database. The reason lies within the design of TDE: the encryption key is stored within master and an attacker with admin privileges on the server can use that to decrypt the database.<br \/>\n&#8211; an attacker who gains access with lower privileges would not be able to access SQL Server database files anyway and hence TDE does not offer further protection.<\/li>\n<li>Backups are automatically encrypted if the database is encrypted. But now comes the bitter reality: <strong>do you keep backups of system databases separate from user database backups? <\/strong>In other words, can someone with access to user database backups also read the system database master\u2019s backup? &#8211; In my 25 years of experience I can only remember 2 clients who went this extra mile. If you\u2019re like most, and you don\u2019t, keep in mind point (2): since the master database contains the master key, an attacker could decrypt user databases as well. Consequently, the encryption may only delay exposure for a few hours or days, depending on the attacker\u2019s skills and the size of the data involved.<\/li>\n<\/ol>\n<p>Ok, so if TDE does not protect data at rest when the system is compromised in a way that allows the attacker access to the master database, what does?<\/p>\n<p>The correct answer is: Always Encrypted.<\/p>\n<h2>Always Encrypted<\/h2>\n<p>Always Encrypted does protect against attacks on data at rest even when the whole server has been compromised. However, it also has many limitations in terms of data types and supported operations and even requires changes in the application. Therefore, one cannot just \u201cturn it on\u201d like TDE. Always Encrypted is a great encryption technology and excels thanks to storing the encryption keys out of reach for SQL Server (if implemented correctly). However, it is not a technology that a DBA alone can decide to use or not.<\/p>\n<p>So yes, please explore this technology further together with your developers. (Link to <a href=\"https:\/\/github.com\/MicrosoftDocs\/sql-docs\/blob\/live\/docs\/relational-databases\/security\/tutorial-getting-started-with-always-encrypted-enclaves.md\" target=\"_blank\" rel=\"noopener\">Tutorial: Getting started using Always Encrypted with secure enclaves in SQL Server<\/a> )<br \/>\nBut it is not a simple let alone complete fix for protecting data at rest either.<\/p>\n<p>What about Backup Encryption?<\/p>\n<h2>Backup Encryption<\/h2>\n<p>As the name says, Backup Encryption is only designed to encrypt the backup files that SQL Server creates. So technically, it protects less than TDE.<\/p>\n<p>However, if you recall the weakness of TDE when a system is compromised (remember that with the key in the system database master every user database can be decrypted), this difference is irrelevant anyway.<\/p>\n<p>Therefore, if we focus on protecting the backup files that are out of control of the SQL Server system, Backup Encryption is doing what you need. Nothing more, nothing less. It protects the database backup files the same way that TDE would do. But without the performance overhead on the live database, let alone TempDB.<\/p>\n<h1>Summary and recommendations<\/h1>\n<p>Let me try to squeeze what we have learned into a comparison matrix:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-6633 size-large\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2025\/01\/202501-Comparison-Protection-TDE-BackupEncryption-AlwaysEncrypted-4-1030x667.jpg\" alt=\"Comparison-Matrix Protection-TDE-BackupEncryption-AlwaysEncrypted\" width=\"1030\" height=\"667\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2025\/01\/202501-Comparison-Protection-TDE-BackupEncryption-AlwaysEncrypted-4-1030x667.jpg 1030w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2025\/01\/202501-Comparison-Protection-TDE-BackupEncryption-AlwaysEncrypted-4-300x194.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2025\/01\/202501-Comparison-Protection-TDE-BackupEncryption-AlwaysEncrypted-4-768x497.jpg 768w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2025\/01\/202501-Comparison-Protection-TDE-BackupEncryption-AlwaysEncrypted-4-705x456.jpg 705w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2025\/01\/202501-Comparison-Protection-TDE-BackupEncryption-AlwaysEncrypted-4.jpg 1200w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" \/><\/p>\n<p style=\"padding-left: 40px;\">* In security, we can\u2019t simply assume the best-case scenario. Plus, experience shows that the typical practice is to store all database backups\u2014both system and user\u2014together in a single central location accessible by SQL Server, and then move them all to another location as a group<\/p>\n<p>It may come as a surprise to some but given that TDE does not make a real difference when it comes to protecting the data stored in SQL Server, I am not promoting TDE to be used as a silver bullet. Yes, on paper, it does encrypt the database. That is a fact. And because of that it may still suffice to get through certain audits. But if your focus is to safeguard your data rather than just getting a checkbox to pass and audit, then you should focus on where it makes a difference.<\/p>\n<p>Here is what I recommend:<\/p>\n<ol>\n<li>Encrypt your Backups using native Backup Encryption with SQL Server\n<ul>\n<li>I am not recommending any specific third-party tool as they introduce another dependency which when the time comes, can be problematic. But this is a decision solely up to you. You can use a third-party app. Just make sure to understand the encryption hierarchy and how the keys are protected.<\/li>\n<li>Make sure to keep the decryption key safely stored in a different location than the backup files<\/li>\n<\/ul>\n<\/li>\n<li>Use Always Encrypted (with secure enclaves) to protect your most sensitive data (PII etc.)\n<ul>\n<li>If you cannot use that, look at the T-SQL functions or use application-side encryption methods.<\/li>\n<\/ul>\n<\/li>\n<li>Use TDE if the Auditor demands it.\n<ul>\n<li>And store system database backups separately if you want to rely on the encryption<\/li>\n<\/ul>\n<\/li>\n<li>Make sure to monitor activity on your server and keep the ACLs for the data and transaction log files tight (which they are by default). Other than administrators no one should be able to (A) stop SQL Server and (B) read the data file directories.\n<ul>\n<li>Here are some links on this subject: <a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/database-engine\/configure-windows\/configure-windows-service-accounts-and-permissions?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Configure Windows service accounts and permissions<\/a>, <a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/database-engine\/configure-windows\/configure-file-system-permissions-for-database-engine-access?view=sql-server-ver16\" target=\"_blank\" rel=\"noopener\">Configure file system permissions for Database Engine access<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>Happy securing<\/p>\n<p>Andreas<\/p>\n<p>Thank you to my <a href=\"https:\/\/www.sarpedonqualitylab.de\/de\/Web\/Page\/Team.aspx\" target=\"_blank\" rel=\"noopener\">Sarpedon Quality Lab Germany team members<\/a>: Torsten Strauss for the idea for this article and Ralf Dietrich and Lars Lawrenz for brainstorming.<\/p>\n<\/div><\/section>\r\n\r\n<div  class='flex_column av-av_one_full-048119fdb636ea3d70edc0b975509c6c av_one_full  avia-builder-el-2  el_after_av_textblock  el_before_av_social_share  first flex_column_div  column-top-margin'     ><div  class='hr av-av_hr-23b3846cdd0fbd0e234720a594f6db24 hr-default  avia-builder-el-3  el_before_av_textblock  avia-builder-el-first '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\n<section  class='av_textblock_section av-av_textblock-564067357eb74c20cdd60b282c9b50bd '   itemscope=\"itemscope\" itemtype=\"https:\/\/schema.org\/BlogPosting\" itemprop=\"blogPost\" ><div class='avia_textblock'  itemprop=\"text\" ><p>Need to secure your own SQL Server environment against these vulnerabilities? Andreas Wolter and the team at Sarpedon Quality Lab offer proprietary, deep-tier security assessments<\/p>\n<\/div><\/section>\n<div  class='avia-button-wrap av-av_button-c6c9e09391f77f3d6785f30b137ea0c9-wrap avia-button-center  avia-builder-el-5  el_after_av_textblock  el_before_av_hr '>\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-av_button-c6c9e09391f77f3d6785f30b137ea0c9\">\n#top #wrap_all .avia-button.av-av_button-c6c9e09391f77f3d6785f30b137ea0c9{\nfont-size:14px;\nbackground-color:#75a823;\nborder-color:#75a823;\ncolor:#ffffff;\nbox-shadow: 0 0 5px 5px ;\ntransition:all 0.4s ease-in-out;\n}\n<\/style>\n<a href=\"https:\/\/sarpedonqualitylab.us\/sql-server-security-assessment\/\" class=\"avia-button av-av_button-c6c9e09391f77f3d6785f30b137ea0c9 avia-icon_select-yes-left-icon avia-size-medium avia-position-center\" target=\"_blank\" rel=\"noopener\"><span class='avia_button_icon avia_button_icon_left' aria-hidden='true' data-av_icon='\ue832' data-av_iconfont='entypo-fontello'><\/span><span class='avia_iconbox_title' >Explore Sarpedon Quality Lab Assessments<\/span><\/a><\/div>\n<div  class='hr av-av_hr-23b3846cdd0fbd0e234720a594f6db24 hr-default  avia-builder-el-6  el_after_av_button  avia-builder-el-last '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div><\/div>\r\n\r\n<div  class='av-social-sharing-box av-5n5vpa-78ffdd9d224b4a246af65bdc00dce900 av-social-sharing-box-default  avia-builder-el-7  el_after_av_one_full  el_before_av_hr  av-social-sharing-box-fullwidth'><div class=\"av-share-box\"><h5 class='av-share-link-description av-no-toc '>Share article<\/h5><ul class=\"av-share-box-list noLightbox\"><li class='av-share-link av-social-link-facebook' ><a target=\"_blank\" aria-label=\"Share on Facebook\" href=\"https:\/\/www.facebook.com\/sharer.php?u=https:\/\/andreas-wolter.com\/en\/protecting-database-data-at-rest-tde-backupencryption-alwaysencrypted\/&#038;t=Protecting%20database%20data%20at%20rest%3A%20Transparent%20Data%20Encryption%2C%20Backup%20Encryption%20or%20Always%20Encrypted\" aria-hidden=\"false\" data-av_icon=\"\ue8f3\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Facebook\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Facebook<\/span><\/a><\/li><li class='av-share-link av-social-link-twitter' ><a target=\"_blank\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=Protecting%20database%20data%20at%20rest%3A%20Transparent%20Data%20Encryption%2C%20Backup%20Encryption%20or%20Always%20Encrypted&#038;url=https:\/\/andreas-wolter.com\/en\/?p=6619\" aria-hidden=\"false\" data-av_icon=\"\ue8f1\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Twitter\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Twitter<\/span><\/a><\/li><li class='av-share-link av-social-link-linkedin' ><a target=\"_blank\" aria-label=\"Share on LinkedIn\" href=\"https:\/\/linkedin.com\/shareArticle?mini=true&#038;title=Protecting%20database%20data%20at%20rest%3A%20Transparent%20Data%20Encryption%2C%20Backup%20Encryption%20or%20Always%20Encrypted&#038;url=https:\/\/andreas-wolter.com\/en\/protecting-database-data-at-rest-tde-backupencryption-alwaysencrypted\/\" aria-hidden=\"false\" data-av_icon=\"\ue8fc\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on LinkedIn\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on LinkedIn<\/span><\/a><\/li><\/ul><\/div><\/div>\r\n\r\n\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-4ofg9q-c2108540b480aba02923089240a3a176\">\n#top .hr.hr-invisible.av-4ofg9q-c2108540b480aba02923089240a3a176{\nheight:50px;\n}\n<\/style>\n<div  class='hr av-4ofg9q-c2108540b480aba02923089240a3a176 hr-invisible  avia-builder-el-8  el_after_av_social_share  el_before_av_comments_list '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\r\n\r\n<div  class='av-buildercomment av-284ftq-f5a1564cd6b8ffad6ce835e2d40de4b7  av-blog-meta-author-disabled av-blog-meta-html-info-disabled'><\/div>","protected":false},"excerpt":{"rendered":"","protected":false},"author":4,"featured_media":6633,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[337,57],"tags":[366,27],"class_list":["post-6619","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-encryption-en","category-security-en","tag-encryption-en","tag-security-en"],"_links":{"self":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/6619","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/comments?post=6619"}],"version-history":[{"count":6,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/6619\/revisions"}],"predecessor-version":[{"id":7457,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/6619\/revisions\/7457"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media\/6633"}],"wp:attachment":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media?parent=6619"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/categories?post=6619"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/tags?post=6619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}