業務でAWSを利用する時に知っておくべきポイント10選 - Qiita
2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro
AWS WAFV2でIPアドレス制限してみた | DevelopersIO
最後に、ホワイトリスト化されていないIPアドレスからのアクセスを遮断するため、 「Default web ACL action for requests that don't match any rules」の Default action を Block にします。 Step 3:Set rule priority ルールが一つしか存在しないため、優先度(priority)の設定は不要です。 デフォルトのまま Next をクリックします。 Step 4:Configure metrics AWS WAFのアクティヴィティをトラッキングしたい場合は、CloudWatch にメトリクスを送信します。 Step 5 : Review and create web ACL 設定内容に問題がなければ、「Create web ACL」ボタンからACLを作成します。 動作確認 Web ACL を動作確
AWSとGCP におけるセキュリティの勘所 - Qiita
AWSやGCPを利用する際によく対面するセキュリティ対応について各クラウドでのソリューションを比較しながら、サービスや方針についてまとめました。 この記事の範囲 主に、Webサービス／アプリ開発でのクラウド利用におけるセキュリティについての話がメインです PCI DSS とか ISMS とかの難しい話はしません(というかできないよ\(^o^)/) パブリッククラウドにおけるセキュリティ パブリッククラウドにおいて、まず最初に押さえるべきは「責任分担モデル」です。簡単にいうと、クラウドサービス自体の運用に関しての責任はクラウドプロバイダが持つ。クラウドサービスの利用の仕方に関する責任は自分たちで持つ。ってやつです。 これは大体どのプロバイダも一緒なので、覚えておくといいと思います。 引用: https://aws.amazon.com/jp/compliance/shared-r
WordPressをXSS攻撃から守るために最低限実施しておきたい対策について | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
9月19日 10:30 ※19:00更新 LIGブログ寄稿ライターによる当記事につきまして、読者の方からいくつかのご指摘を受けました。 記事内で不正確な表現を使用していたため、内容に誤りがありました。一度記事を取り下げ、記事内容を精査・修正いたしましたので、再掲載させていただきます。大変申し訳ありませんでした。 引き続き、情報の精度向上に努めて参りますので、よろしくお願いいたします。 LIGブログ編集部 どうもコンニチワ……モリイです。夏場の暑さをなんとか乗り切り、すっかり気が抜けてしまっている今日この頃です。すみません、愚痴ってしまいました。 さて、XSS攻撃による被害がかなり増えています。もはや他人ごとではなく、明日あなたが管理しているサイトがXSS攻撃されてもおかしくないレベルで被害は拡大しているのです。 実際、本業ではWordPress専用のセキュリティ診断サービスを運営している私
AWS セキュリティ監査のガイドライン - AWS Identity and Access Management
セキュリティ設定を定期的に監査し、現在のビジネスニーズに対応していることを確認します。監査により、不要な IAM ユーザー、ロール、グループ、ポリシーを削除し、ユーザーとソフトウェアに対する過剰なアクセス許可がないことを確認する機会が得られます。 以下では、セキュリティのベストプラクティスを実践するために、AWS リソースを体系的に確認し、モニタリングするためのガイドラインを示します。 AWS Security Hub を使用して、セキュリティのベストプラクティスに関連する IAM の使用状況をモニタリングできます。Security Hub は、セキュリティコントロールを使用してリソース設定とセキュリティ標準を評価し、お客様がさまざまなコンプライアンスフレームワークに準拠できるようサポートします。Security Hub を使用して IAM リソースを評価する方法の詳細については、「AWS
二段階認証JAVA実現（TOTP） - Qiita
1.はじめに ある社内システムを外部へ公開により、セキュリティ対策を強化するため、ログインの二段階認証を実現したい。ITエンジニアの私として、二段階認証の実現方法を検討します。 2.二段階認証の使用流れ 各サイトに二段階認証機能を使うと、QRコードをスキャンしてから、認証アプリをアカウントに登録するよう求めるメッセージが表示 色々認証アプリがあり、例えば、Google Authenticator、Authy、Duo Mobile、1Passwordなど(時間ベースのワンタイムパスワード（TOTP）認証アプリ) QRコードをスキャンしたら、認証アプリにより、30秒ごとにパスワードを生成される 普通のログインパスワード以外、該当パスワードは二段階認証コードとして使う 3.TOTP 時間によってワンタイムパスワードが計算される仕組みから「Time-based One-Time Password」
二段階認証を実装するまでに調べたこと - Qiita
二段階認証を実装するにあたり、自分が調べたことをまとめました。 何か間違ったことがあれば、コメントいただけると幸いです！ 二段階認証?二要素認証 英語では、二段階認証を「Two-Factor-Auth」と訳しますが、日本語では「二段階認証」と「二要素認証」は明確に異なります。 二段階認証の説明をする前に、認証の3要素について説明する必要があります。 認証の三要素 私たちが普段Webサービスを利用する際に、アカウントが自分のものか、認証を行います。その代表的な手段として「メールアドレス」と「パスワード」が一般的です。ですが、一個人を特定する方法として、他にも種類があります。それらを3つに分類したものを「認証の3要素」と呼んだりします。以下のように分けられます。 ユーザが知っていること（知識情報） ID・パスワード 秘密の質問 ユーザが持っているもの（所持情報） 電話番号 キャッシュカード ワ
自社サービスにスマホアプリによる2段階認証を導入する - Qiita
目的 開発者が自社サービスに導入するときに知っておきたい情報がまとまってて欲しい 非エンジニアだけどサービス画面などを設計する人に説明するときの図が欲しい 概要 ユーザーにスマホアプリをインストールしてもらって、アプリが発行したトークンをワンタイムパスワード(以下OTP)として使用する フロー 編集 これでWebサーバーとユーザーのアプリで鍵(shared secret)が共有されます。 編集 生成されるトークンは30秒毎に変化する（時間は変更可能）。逆に言うと30秒間は何度計算しても同じトークンが生成される。サーバーとクライアントで同一時間帯に同一ロジックでトークンを生成することで同じトークンが生成されるので、これをOTPとして利用する。30秒毎の切り替えのタイミングで生成してしまうと認証に失敗するので再入力を簡単に行えるような画面設計がいいかも(Appleのデバイス認証みたいに各桁独立
このユーザーはこの機能が使える、みたいなあれをどう実現するか
このユーザーはこの機能が使える、みたいなあれをどう実現するか 新しい記事公開しました！ 結論 DBで実現するかアプリケーション側でライブラリで実現する。casbinが強そうだぞ。 はじめに ユーザーテーブルにisAdminというカラムを使って、アドミンかそうでないかで、アクセスコントロールを分けていたが、サービスが大きくなり、もう少し細かくコントロールする必要になった。そこで、情報収集してえた見識をまとめておく。 アクセスコントロールという考え方を知る だれがこのファイルを操作できるのかみたいなやつ。おおきく4つのパターンがあるみたい。 DAC RBAC MAC ABAC DACとRBACとMAC この３つはまとめて図で理解したほうが覚えやすいと思う。 DAC(任意アクセス制御)はユーザー側が任意にこの機能を誰が使えるか設定する。例えばgoogleでファイル共有するときに誰までが閲覧可能か
業務システムにおけるロールベースアクセス制御 - Qiita
RBACの基礎 業務システムの権限制御の基本形はロールベースアクセスコントロール(RBAC)です。簡単化すると、以下のようなモデルです。 Subject(システムユーザ)は、複数のRole(ロール)を持っている。 Role(ロール)は、Permission(権限)のセットからなる。 Permission(権限)は、オペレーション(許可される操作)のセットからなる 具体的に、Redmineでの例をみてみましょう。 ユーザにはデフォルトで「管理者」「開発者」「報告者」のロールが割当可能である。 「報告者」ロールは、「Add Issues」の権限をもつ。 「Add Issues」の権限をもつユーザは、「Issueの新規作成」ができる。 このモデルをRedmineでは、以下のように表現しています。 Redmineは1人のユーザを、複数のプロジェクトに異なるロールでアサインすることができるので、上記
Firebase Authentication 7つの落とし穴 - 脆弱性を生むIDaaSの不適切な利用 - Flatt Security Blog
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 不十分な対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2
IAP のカスタマイズ | Identity-Aware Proxy | Google Cloud
フィードバックを送信 IAP のカスタマイズ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 この記事では、Identity-Aware Proxy（IAP）の設定をカスタマイズする方法について説明します。この設定により、以下のような動作を制御できます。 Google Kubernetes Engine での GKE Enterprise と Istio の互換性。 CORS のプリフライト リクエストの処理 ユーザーの認証方法 アクセスが拒否されたときにユーザーに表示されるエラーページ 設定の管理 Google Cloud コンソール、IAP API、または Google Cloud CLI を使用して、ロードバランサと App Engine アプリの IAP 設定を表示および更新できます。 フォルダ、プロジェクト、組織など、すべてのリソースの IAP
外部 ID によるセッションの管理 | Identity-Aware Proxy | Google Cloud
フィードバックを送信 外部 ID によるセッションの管理 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 この記事では、認証に外部 ID を使用する場合に Identity-Aware Proxy（IAP）でセッションを管理する方法について説明します。 セッションの更新 Identity Platform セッションの有効期間は 1 時間です。セッションが期限切れになったら、アプリを認証ページにリダイレクトする必要があります。認証ページには Identity Platform の更新トークンが含まれています。ユーザーの認証情報が有効であれば、UI を表示することなく、その認証情報で再度認証を行うことができます。 ユーザーが最近メールアドレスまたはパスワードを変更したか、別の操作でトークンが取り消された場合は、再度認証フローを完了する必要があります。 AJA
クイックスタート: 外部 ID を使用したユーザーの認証 | Identity-Aware Proxy | Google Cloud
フィードバックを送信 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 外部 ID を使用してユーザーを認証する このクイックスタートでは、Identity-Aware Proxy（IAP）と外部 ID でアプリを保護する方法について説明します。IAP と Identity Platform を組み合わせることで、Google アカウントだけでなく、OAuth、SAML、OIDC など、さまざまな ID プロバイダを使用してユーザーの認証を行うことができます。 このクイックスタートでは、Facebook 認証を使用して App Engine のサンプルアプリを保護します。 始める前に Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。 プロジェクト セレクタに移動
BeyondCorp Enterpriseを徹底解説。 Googleで実現するゼロトラスト・セキュリティ - G-gen Tech Blog
G-gen の杉村です。情報セキュリティの世界でゼロトラストというキーワードが半ばバズワードのように取り上げられるようになってから久しくなりました。Google のゼロトラスト・ソリューションとして BeyondCorp Enterprise があります。 当記事の前半では、BeyondCorp の基本的な概念や構成を説明します。後半 (第4項以降) は、BeyondCorp の各構成要素を詳細に説明しますので、技術者の方向けです。 BeyondCorp Enterprise の概要 BeyondCorp Enterprise とは ゼロトラストセキュリティとは 構成要素 運用 ID（ユーザーアカウント） 外部 ID 連携 監査ログ 料金 BeyondCorp Enterprise の料金 その他の課金 無料範囲 技術的な詳細解説 01. Identity-Aware Proxy (IAP
買ったらまず実施！RaspberryPiのセキュリティ対策 - Qiita
はじめに 本記事は主にこちらを参考にさせて頂きました。 https://qiita.com/mochifuture/items/00ca8cdf74c170e3e6c6 https://qiita.com/nokonoko_1203/items/94a888444d5019f23a11 買ってすぐのRaspberryPi本体へ適用する前提での方法となります。 私はセキュリティの専門家ではないので、下記だけでは不十分だ！という意見があれば、 積極コメント頂けるとありがたいです！ 必要なもの ・RaspberryPi (本例ではRaspberryPi3 ModelB) ・PC (SSH接続の確認に使用。本例ではWindows10) ・上記RaspberryPiとPCのLAN接続環境（ルータにつなげばOK） RaspberryPiとセキュリティ 安価で必要十分な性能を備えるRaspberrypP
Dockerfileのベストプラクティス Top 20
本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ
「私はロボットではありません」はワンクリックでなぜ人間を判別できる？ 仕組みとその限界を聞いてきた
2021.02.16 「私はロボットではありません」はワンクリックでなぜ人間を判別できる？ 仕組みとその限界を聞いてきた WebサイトにIDとパスワードを入力するとき、ときどき「私はロボットではありません」にチェックを求められることがあります。 僕はロボットではないので、当然チェックを入れて認証を進めるわけですが……。でもちょっと待ってください。なぜクリックひとつで、人間かロボットかを判断できるんでしょう。 これはきっと、人間ではないなんらかの不正アクセスを防ぐ仕組みのはず。でもチェックを入れるくらい、プログラムを作ってなんやかんやすれば、シュッとできるのでは？ 「私はロボットではありません」は、どんな仕組みで人間とロボットを判別しているのか。もっといい方法はないのか。これまでの歴史的経緯も含め、情報セキュリティ大学院大学の大久保隆夫教授に聞きました。 気づかないうちに「人間かロボットか」
セキュリティ情報の集め方 ～しなもんの場合～ - 午前７時のしなもんぶろぐ
あけましておめでとうございます。 今年も細々とながら発信を続けていこうと思いますので、どうかよろしくお願いします。 今回はセキュリティ情報 (公開情報) の集め方について、私がどのようにしているのかご紹介します。 これがベストというわけではなく、このとおりやればいいというわけでもなく、あくまでひとつのケースとしてお考えください。 ※「誰それをフォローするといいよ！」といった個別具体的な情報源の紹介はしません。 最後にご紹介する他のリサーチャの方の中には情報源のリストを公開されている方もいらっしゃるので、ニーズに合いそうならそれらの情報源を利用されるとよいと思います。 なぜ情報収集をするのか どんな情報を集めるか 具体的な情報収集の方法について RSS リーダー Inoreader RSS を配信していないサイトの対策 Twitter TweetDeck 英語について 情報収集の注意点 他の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://s3.amazonaws.com/awsmedia/AWS+Auditing+Security+Checklist+Whitepaper_Japanese.pdf