构建meteor应用程序_如果要构建安全的树屋（或软件应用程序），请从底部开始...
构建meteor应用程序
If you’ve ever watched a kid draw a treehouse, you have some idea of how applications are built when security isn’t made a priority.
如果您曾经看过一个孩子画一棵树屋，那么您将对如何在不将安全放在首位的情况下构建应用程序有所了解。
It’s far more fun to draw the tire swing, front porch, and swimming pool than to worry about how a ten-thousand-gallon bucket of water stays suspended in midair.
绘制轮胎Swing，前廊和游泳池要比担心一万加仑的水如何悬浮在空中更有趣。
With too much attention spent on fun and flashy features, foundations suffer.
由于对娱乐性和浮华功能的投入过多，基础受到了影响。
Of course, spending undue hours building a back end like Fort Knox may not be necessary for your application, either. Being an advocate for security doesn’t mean always wearing your tinfoil hat (although you do look dashing in it) but does mean building in an appropriate amount of security.
当然，对于您的应用程序，也不必花费过多的时间来构建像Fort Knox这样的后端。 倡导安全性并不意味着总是戴上锡箔帽子(尽管看起来确实有些破破烂烂)，而是意味着要建立适当数量的安全性。
How much security is appropriate? The answer, frustratingly, is, “it depends.” The right amount of security for your application depends on who’s using it, what it does, and most importantly, what undesirable things it could be made to do.
多少安全性合适？ 令人沮丧的答案是，“取决于情况”。 应用程序的适当安全性取决于谁在使用它，它在做什么，以及最重要的是，可以使它做什么令人讨厌的事情。
It takes some analysis to make decisions about the kinds of risks your application faces and how you’ll prepare to handle them. Okay, now’s a good time to don your tinfoil hat. Let’s imagine the worst.
需要进行一些分析才能对应用程序面临的风险种类以及如何准备应对这些风险做出决策。 好吧，现在是戴上锡箔帽子的好时机。 让我们想象最坏的情况。
威胁建模：最糟糕的情况是什么？ (Threat modeling: what’s the worst that could happen?)
A threat model is a stuffy term for the result of trying to imagine the worst things that could happen to an application. Using your imagination to assess risks (fittingly called risk assessment) is a conveniently non-destructive method for finding ways an application can be attacked.
威胁模型是一个令人讨厌的术语，表示试图想象应用程序可能发生的最坏情况的结果。 利用您的想象力来评估风险(适当地称为风险评估 )是一种方便的，无损的方法，可用于发现攻击应用程序的方式。
You won’t need any tools – just an understanding of how the application might work, and a little imagination. You’ll want to record your results with pen and paper. For the younger folks, that means the notes app on your phone.
您将不需要任何工具-只需了解应用程序的工作方式，并需要一点想象力。 您将要用笔和纸记录您的结果。 对于年轻人来说，这意味着您手机上的笔记应用程序。
A few different methodologies for application risk assessment can be found in the software world, including the in-depth NIST Special Publication 800-30. Each method’s framework has specific steps and output, and will go into various levels of detail when it comes to defining threats.
在软件界可以找到几种不同的应用程序风险评估方法，包括深入的NIST特别出版物800-30 。 每种方法的框架都有特定的步骤和输出，并且在定义威胁时会涉及各种详细级别。
If following a framework, first choose the one you’re most likely to complete. You can always add more depth and detail from there.
如果遵循框架，请首先选择最有可能完成的框架。 您始终可以从那里添加更多的深度和细节。
Even informal risk assessments are beneficial. Typically taking the form of a set of questions, they may be oriented around possible threats, the impact to assets, or ways a vulnerability could be exploited.
甚至非正式的风险评估也是有益的。 通常以一系列问题的形式出现，它们可能针对可能的威胁，对资产的影响或漏洞利用的方式。
Here are some examples of questions addressing each orientation:
以下是一些针对每个方向的问题示例：
- What kind of adversary would want to break my app? What would they be after? 什么样的对手想要破坏我的应用程序？ 他们会追求什么？
If the control of x fell into the wrong hands, what could an attacker do with it?
如果x的控制权落入错误的人手中，那么攻击者将如何处理它？
Where could x vulnerability occur in my app?
我的应用程序中哪里会出现x漏洞？
A basic threat model explains the technical, business, and human considerations for each risk. It will typically detail:
基本威胁模型说明了每种风险的技术，业务和人员考虑因素。 它通常会详细说明：
- The vulnerabilities or components that can cause the risk 可能导致风险的漏洞或组件
- The impact that a successful execution of the risk would have on the application 成功执行风险会对应用程序产生影响
- The consequences for the application’s users or organization 对应用程序用户或组织的后果
The result of a risk assessment exercise is your threat model. In other words, it's a list of things you would very much like not to occur.
风险评估活动的结果就是您的威胁模型。 换句话说，这是您非常希望不会发生的事情的列表。
It is usually sorted in a hierarchy of risks, from the worst to the mildest. The worst risks have the most negative impact, and are most important to protect against. The mildest risks are the most acceptable — while still an undesirable outcome, they have the least negative impact on the application and users.
通常按照从最坏到最轻的风险等级进行分类。 最严重的风险具有最大的负面影响，因此最重要的是要防范。 最小的风险是最可接受的-尽管仍然是不希望的结果，但它们对应用程序和用户的负面影响最小。
You can use this resulting hierarchy as a guide to determine how much of your cybersecurity efforts to apply to each risk area. An appropriate amount of security for your application will eliminate (where possible) or mitigate the worst risks.
您可以使用由此产生的层次结构作为指导，以确定将多少网络安全工作应用于每个风险区域。 为您的应用程序提供适当数量的安全性将消除(在可能的情况下)或减轻最严重的风险。
向左推 (Pushing left)
Although it sounds like a dance move meme, pushing left refers instead to building in as much of your planned security as possible in the early stages of software development.
尽管这听起来像是跳动模因，但向左推是指在软件开发的早期阶段尽可能多地构建计划的安全性。
Building software is a lot like building a treehouse, just without the pleasant fresh air. You start with the basic supporting components, such as attaching a platform to a tree. Then comes the framing, walls, and roof, and finally, your rustic-modern Instagram-worthy wall hangings and deer bust.
构建软件非常类似于构建树屋，只是没有宜人的新鲜空气。 您从基本的支持组件开始，例如将平台附加到树上。 然后是框架，墙壁和屋顶，最后是您的乡村风格现代值得Instagram使用的壁挂和鹿胸围。
The further along in the build process you are, the harder and more costly it becomes to make changes to a component that you’ve already installed.
您在构建过程中走得越远，对已安装的组件进行更改就越困难且成本更高。
If you discover a problem with the walls only after the roof is put in place, you may need to change or remove the roof in order to fix it. Similar parallels can be drawn for software components, only without similar ease in detangling the attached parts.
如果仅在屋顶安装到位后才发现墙壁有问题，则可能需要更换或拆除屋顶以进行固定。 可以为软件组件绘制相似的相似之处，只是在缠结附加零件方面没有相似的便利。
In the case of a treehouse, it’s rather impossible to start with decorations or even a roof, since you can’t really suspend them in midair.
就树屋而言，几乎不可能从装饰甚至屋顶开始，因为您无法真正将它们悬挂在空中。
In the case of software development, it is, unfortunately, possible to build many top-layer components and abstractions without a sufficient supporting architecture.
不幸的是，在软件开发的情况下，无需足够的支持架构就可以构建许多顶层组件和抽象。
A push-left approach views each additional layer as adding cost and complication. Pushing left means attempting to mitigate security risks as much as possible at each development stage before proceeding to the next.
左推方法将每个额外的层视为增加成本和复杂性。 向左推表示在每个开发阶段都尝试尽可能降低安全风险，然后再进行下一个阶段。
从下到上的建筑 (Building bottom-to-top)
By considering your threat model in the early stages of developing your application, you reduce the chances of necessitating a costly remodel later on. You can make choices about architecture, components, and code that support the main security goals of your particular application.
通过在开发应用程序的早期阶段考虑威胁模型，可以减少以后需要进行昂贵的重塑的机会。 您可以选择支持特定应用程序主要安全目标的体系结构，组件和代码。
While it’s not possible to foresee all the functionality your application may one day need to support, it is possible to prepare a solid foundation that allows additional functionality to be added more securely. Building in appropriate security from the bottom to the top will help make mitigating security risks much easier in the future.
虽然无法预见您的应用程序一天可能需要支持的所有功能，但可以为扎实的基础做准备，以便更安全地添加其他功能。 从底部到顶部建立适当的安全性将有助于减轻将来的安全风险。
翻译自: https://www.freecodecamp.org/news/if-you-want-to-build-a-treehouse-start-at-the-bottom/
构建meteor应用程序