[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-0-en-105":3,"doc-seo-657634-105":59,"doc-detail-657634-en":122},{"code":4,"msg":5,"data":6},0,"success",[7,13,18,23,28,33,38,43,48,51,55],{"id":8,"doc_module":4,"doc_module_name":9,"category_name":10,"show_sort_weight":11,"slug":12},1,"Document","Story & Novel",90,"story-novel",{"id":14,"doc_module":4,"doc_module_name":9,"category_name":15,"show_sort_weight":16,"slug":17},2,"Literature",80,"literature",{"id":19,"doc_module":4,"doc_module_name":9,"category_name":20,"show_sort_weight":21,"slug":22},4,"Exam",70,"exam",{"id":24,"doc_module":4,"doc_module_name":9,"category_name":25,"show_sort_weight":26,"slug":27},5,"Comic",60,"comic",{"id":29,"doc_module":4,"doc_module_name":9,"category_name":30,"show_sort_weight":31,"slug":32},6,"Technology",50,"technology",{"id":34,"doc_module":4,"doc_module_name":9,"category_name":35,"show_sort_weight":36,"slug":37},7,"Healthcare",40,"healthcare",{"id":39,"doc_module":4,"doc_module_name":9,"category_name":40,"show_sort_weight":41,"slug":42},8,"Research & Report",30,"research-report",{"id":44,"doc_module":4,"doc_module_name":9,"category_name":45,"show_sort_weight":46,"slug":47},9,"Religion & Spirituality",20,"religion-spirituality",{"id":46,"doc_module":4,"doc_module_name":9,"category_name":49,"show_sort_weight":46,"slug":50},"World Cup","world-cup",{"id":52,"doc_module":4,"doc_module_name":9,"category_name":53,"show_sort_weight":52,"slug":54},10,"Lifestyle","lifestyle",{"id":56,"doc_module":4,"doc_module_name":9,"category_name":57,"show_sort_weight":24,"slug":58},19,"General","general",{"code":4,"msg":60,"data":61},"ok",{"site_id":62,"language":63,"slug":64,"title":65,"keywords":66,"description":67,"schema_data":68,"social_meta":115,"head_meta":117,"extra_data":119,"updated_unix":121},105,"en","beyondcorp-design-to-deployment-at-google","BeyondCorp: Design to Deployment at Google","","BeyondCorp outlines how Google moved from traditional perimeter-based security to a model that treats internal and external networks as untrusted. The approach grants application access through dynamic, policy-driven tiers based on device state, user association, and real-time credentials. The paper details core system components—trust inference, device inventory, access policy, centralized enforcement, gateways, and resources—along with practical deployment considerations such as inventory, device versus host distinctions, and tiered authorization requirements.",{"@graph":69,"@context":114},[70,84,105],{"@type":71,"itemListElement":72},"BreadcrumbList",[73,77,79,82],{"item":74,"name":75,"@type":76,"position":8},"https://docshare.wps.com","Home","ListItem",{"item":78,"name":9,"@type":76,"position":14},"https://docshare.wps.com/document/",{"item":80,"name":40,"@type":76,"position":81},"https://docshare.wps.com/document/research-report/",3,{"item":83,"name":65,"@type":76,"position":19},"https://docshare.wps.com/document/beyondcorp-design-to-deployment-at-google/657634/",{"url":83,"name":65,"@type":85,"image":86,"author":91,"headline":65,"publisher":94,"fileFormat":97,"inLanguage":63,"description":67,"dateModified":98,"datePublished":99,"encodingFormat":97,"isAccessibleForFree":100,"interactionStatistic":101},"DigitalDocument",{"url":87,"@type":88,"width":89,"height":90},"https://docshare.wps.com/thumbnails/beyondcorp-design-to-deployment-at-google/657634.png","ImageObject",300,407,{"name":92,"@type":93},"iuabcfuw","Person",{"url":74,"name":95,"@type":96},"DocShare","Organization","application/pdf","2026-10-29","2026-10-26",true,{"@type":102,"interactionType":103,"userInteractionCount":8},"InteractionCounter",{"@type":104},"ViewAction",{"@type":106,"mainEntity":107},"FAQPage",[108],{"name":109,"@type":110,"acceptedAnswer":111},"What problem does the BeyondCorp initiative address?","Question",{"text":112,"@type":113},"Q2","Answer","https://schema.org",{"og:url":83,"og:type":116,"og:title":65,"og:site_name":95,"og:description":67},"article",{"robots":118,"canonical":83},"index,follow",{"doc_id":120,"site_id":62},657634,1792985724,{"code":4,"msg":5,"data":123},{"doc_id":120,"user_id":124,"nickname":92,"user_avatar":125,"doc_module":4,"category_id":39,"category_name":40,"doc_title":65,"doc_description":67,"doc_content":126,"file_id":127,"file_url":128,"file_type":129,"file_size":130,"view_count":8,"is_deleted":4,"is_public":8,"is_downloadable":8,"audit_status":8,"page_count":39,"language":131,"language_code":63,"site_id":62,"html_lang":63,"table_of_contents":132,"faqs":133,"seo_title":134,"seo_description":67,"update_tm":121,"read_time":46},3985747874027,"https://ap-avatar.wpscdn.com/davatar_9964176cb1d06d4a9deccf72a44ae3dc","BeyondCorp  \nDesign to Deployment at Google  \nB A R C L AY O S B O R N , J U S T I N M C W I L L I A M S , B E T S Y B E Y E R , A N D M A X S A LT O N S TA L L  \nBarclay Osborn is a Site Reliability Engineering Manager at Google in Los Angeles . He previously worked at a variety of software, hardware, and security startups in San Diego. He holds a BAin computer science from the University of California, San [Diego.](Diego. barclay@google.com)[ barclay@google.com](Diego. barclay@google.com)  \nJustin McWilliams is a Google Engineering Manager based in NYC. Since joining Google in 2006, he has held positions in IT Support and I T Ops Focused Software Engineering. He holds a BA from the University of Michigan, Ann Arbor.  \n[jjm@google.com](jjm@google.com)  \nBetsy Beyer is a Technical Writer for Google Site Reliability Engineering in NYC. She has previously provided documentation for Google Data Center and Hardware Operations teams . Before moving to New York, Betsy was a lecturer in technical writing at Stanford University. She holds degrees from Stanford  \nand [Tulane.](Tulane. bbeyer@google.com)[ bbeyer@google.com](Tulane. bbeyer@google.com)  \nMax Saltonstal l is a Program Manager for Google Corporate Engineering in New York.  \nSince joining Google in 2011 he has worked on advertising products, internal change management, and IT external ization . He has a degree in computer science and psychology from Yale .  \n[maxsaltonstall@google.com](maxsaltonstall@google.com)  \nThe goal of Google’s BeyondCorp initiative is to improve our security  \nwith regard to how employees and devices access internal applica  \ntions. Unlike the conventional perimeter security model, BeyondCorp doesn’t gate access to services and tools based on a user’s physical location or the originating network; instead, access policies are based on information about a device, its state, and its associated user. BeyondCorp considers both internal networks and external networks to be completely untrusted, and gates access to applications by dynamically asserting and enforcing levels, or“tiers,” of access.  \nWe present an overview of how Google transitioned from traditional security infrastructure to the BeyondCorp model and the challenges we faced and the lessons we learned in the process. For an architectural discussion of BeyondCorp, see [1] .  \nOverview  \nAs illustrated by Figure 1, the fundamental components of the BeyondCorp system include the Trust Inferer, Device Inventory Service, Access Control Engine, Access Policy, Gateways, and Resources. The following list defines each term as it is used by BeyondCorp:  \n◆ Access requirements are organized into Trust Tiers representing levels of increasing sensitivity.  \n◆ Resources are an enumeration of all the applications, services, and infrastructure that are subject to access control. Resources might include anything from online knowledge bases, to financial databases, to link-layer connectivity, to lab networks. Each resource is associated with a minimum trust tier required for access.  \n◆ The Trust Inferer is a system that continuously analyzes and annotates device state. The system sets the maximum trust tier accessible by the device and assigns the VLAN to be used by the device on the corporate network. These data are recorded in the Device Inventory Service. Reevaluations are triggered either by state changes or by a failure to receive updates from a device.  \n◆ The Access Policy is a programmatic representation of the Resources, Trust Tiers, and other predicates that must be satisfied for successful authorization.  \n◆ The Access Control Engine is a centralized policy enforcement service referenced by each gateway that provides a binary authorization decision based on the access policy, output of the Trust Inferer, the resources requested, and real-time credentials.  \n◆ Atthe heart of this system, the Device Inventory Service continuously collects, processes, and publishes changes about the state of known devic","cbCaia3eokkTsFiQ","https://ap.wps.com/l/cbCaia3eokkTsFiQ","pdf",855664,"English","# Overview\n## Architecture of the BeyondCorp Infrastructure Components\n# Components of BeyondCorp\n## Devices and Hosts\n## Tiered Access","[{\"question\":\"What problem does the BeyondCorp initiative address?\",\"answer\":\"Q2\"}]","BeyondCorp: Design to Deployment at Google | PDF"]