SASE(Secure Access Service Edge)は、ネットワークやセキュリティーに関する複数のクラウドサービスの機能を集約して一元的に提供するサービスである。調査会社の米ガートナーが2019年に提唱した。複数のサービスを集約して一元的に提供するセキュリティーの考え方をSASEと呼ぶ場合もある。 5つのクラウドサービスが核 ガートナーはSASEを構成するサービスを厳密には定義していない。だがCASB(Cloud Access Security Broker)、NGFW(Next Generation FireWall)、SD-WAN(Software Defined-WAN)、SWG(Secure Web Gateway)、ZTNA(Zero Trust Network Access)の5つのサービスが、SASEを実現する上で特に重要であるとされている。実際SASEを名乗るサ
Today we’re delighted to introduce Tailscale SSH, to more easily manage SSH connections in your tailnet. Tailscale SSH allows you to establish SSH connections between devices in your Tailscale network, as authorized by your access controls, without managing SSH keys, and authenticates your SSH connection using WireGuard®. Many organizations already use Tailscale to protect their SSH sessions — for
今回から複数回に分けて、WindowsのAccess Control List(ACL、アクセス制御リスト)を解説することにする。ACLは、Windowsの中でも面倒な部分の1つで理解しなくても特に困るというものでもないが、複雑なファイルアクセス権の管理(あの人たちにファイルを見せたくないけど、自分たちは編集できる)をする場合、避けて通れないことがある。 ACLが面倒なのは、Windowsでは直接見えにくいものだからだ。ただし、すべてのオブジェクトのACLを説明することはかなり大変なので、ここでは対象をファイルシステム(ファイルとディレクトリ)に限定することにする。と言っても、ファイルシステム固有の部分があるだけで、基本はどのACLも同じである。 Windowsでファイルやディレクトリにアクセスできないことがあるが、それはアクセス権を持っていないから。それぞれのファイルやディレクトリに対す
Now when aws executes it does so from within an op run context. When it’s time to locate the access secrets aws does what it always does, but there is no (plain text) ~/.aws/credentials RC file for it to use. It does, however, find some magical $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY beans environment variables. These variables use the secret reference syntax to specify that their values nee
私がこのDevelopers IOでも屈指の良エントリだと思っているのが、以下の佐伯さんのエントリです。 ディレクトリ移動をするだけでAWSのクレデンシャルを切り替えてくれるので、複数のAWSアカウントに対してCLIベース(私はTerraformを使うことが多い)で作業をするような方にはとてもおすすめです。一度お試しください。 M1 Macでは動かなかった 最近開発環境をM1 Macに変えました。するとこの仕組みが動作しませんでした。 環境情報 MacBook Pro (13-inch, M1, 2020) チップ: Apple M1 OS: MacOS Big Sur (バージョン11.6.2) 原因 上記仕組みはdirenvとassume-roleという2つのツールを組み合わせて実現されているのですが、assume-roleがM1に対応していないようです。 % assume-role
はじめに こんにちは。ご無沙汰しております。脆弱性診断員の百田です。 今回は、実際に脆弱性診断をしていたときに考えていた、そこまで重要でもないと思われることをここに吐き出します。 その内容は、題名にもあるとおりレスポンスヘッダの「Access-Control-Allow-Origin」に設定される値についてです。 注意点として「Access-Control-Allow-Origin」に設定される値自体はどうでも良くないです。重要です。 理由がよくわからない場合は以下の記事をご覧いただければと思います。 https://developer.mozilla.org/ja/docs/Web/HTTP/CORS では、そこまで重要でもないと思ったのは何なのか……。それは「Access-Control-Allow-Origin」に以下の値が設定されていた場合、どちらがセキュリティ的にマシなのか?とい
「Private Access Tokens」という提案仕様が、Google, Apple, Fastly, Cloudflareの方々らの共著でIETFに提出されています。なお、すでに実装が進められているそうです。 この「Private Access Tokens」の一つのモチベーションに次のようなものがあります。 昨今、プライバシー保護の要求は高まっており、ユーザのIPアドレスを秘匿する、iCloud Private RelayやOblivious HTTPといった技術が出てきています。いままではIPアドレスベースでアクセスレートリミットを行っていましたが、 そのような環境でも、アクセスのレートリミットを設けたいというというのが一つの目的です。 それを、追加のユーザインタラクション無しに、かつユーザをトラッキングできないような匿名なトークンで行うというのがPrivate Access
CX事業本部@大阪の岩田です。CloudFrontに待望のアップデートがあり、CloudFront単体でもレスポンスヘッダーが設定できるようになりました! これまではCloudFront単体でレスポンスヘッダーを設定することができませんでした。S3 & CloudFrontの構成でSPAを配信するのは非常に一般的な構成ですが、この構成でそのまま脆弱性診断を受けると、セキュリティ関連のヘッダが設定されていないと指摘されるのも「あるある」でした。Lambda@Edge(L@E)やCloudFront Function(CF2)を介入させればオリジンレスポンスやビュワーレスポンスが加工できるので、これまではL@EやCF2でレスポンスヘッダを追加付与するという対応がよく採用されていました。 が、静的なレスポンスヘッダ付与のためにいちいちコードの実行が必要になるというのは、どうも無駄が多いように感じ
October 27, 2021 Pull Request Merge Queue is now available in limited beta. Learn more about the feature and how to request early access. Why a merge queue? Maintaining high velocity and keeping your main branch green can be a challenge today. Many repositories try to do this by requiring all pull requests be up to date with the main branch before merging. This ensures the main branch is never upd
October 27, 2021 GitHub Actions now supports OpenID Connect (OIDC) for secure deployments to cloud, which uses short-lived tokens that are automatically rotated for each deployment. This enables: Seamless authentication between Cloud Providers and GitHub without the need for storing any long-lived cloud secrets in GitHub Cloud Admins can rely on the security mechanisms of their cloud provider to e
コンバンハ、千葉(幸)です。 AWS CLI (など)を使用するためにアクセスキーを設定する際、皆さんは以下のような手順をとるのではないでしょうか。 「ひとまずaws configureを叩く。」 $ aws configure ↑(--profileオプションを付与すれば名前付きプロファイルへの設定となりますが、デフォルトではdefaultというプロファイルに対する設定となります。) 「各項目の入力が促されるため、必要な項目を入力していく。」 $ aws configure AWS Access Key ID [None]: #アクセスキーを入力 AWS Secret Access Key [None]: #シークレットキーを入力 Default region name [None]: ap-northeast-1 Default output format [None]: ↑(ここでは
はじめに 必要に応じて検証環境の追加・削除などの管理をするのが面倒くさいので、PR作成時に検証環境を構築、PRマージ・クローズ時に検証環境を削除ができないか考えてみました。 今回の作成したGitHub Actions ワークフロー、Terraformなどはこちらのリポジトリにあります。 概要図 どのように実現したか 実現あたり、コンテナイメージのプッシュ、ECS サービスのデプロイはGitHub Actions、Terraformの実行はAWS CodeBuildで行うことにしました。 なぜTerraformの実行はCodeBuildを利用するようにしたかというと、CodeBuildはVPC内のリソース(今回の場合はAurora Serverless)にアクセスできるからです。 これによってアプリケーション、DBマイグレーション時に使用するMySQL ユーザーをTerraformで作成する
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXkRead less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く