サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
oji-cloud.net
Linuxセキュリティ強化: sshの暗号方式からcbcモードを無効化する 前提条件 Linux のセキュリティ強化の設定を紹介します。今回は、SSHで使われる暗号方式について、CBCモード(Cipher Block Chaining)を無効化し、CTRモード(CounTR )など別のモードを使うように変更します。 対象は、sshd(対象システムがsshサーバーとなる)およびssh(対象システムがsshクライアントとなる)です。 暗号方式におけるアルゴリズム、モードは下記記事が大変勉強になります。 設定手順 現在の環境でサポートされている暗号化方式を確認します。6つの暗号方式でcbcモードを使用していることが確認できます。 下記コマンドは、暗号方式の有効/無効に関わらず結果に使用可能なすべての方式が表示されるため、ご注意ください。 $ ssh -Q cipher 3des-cbc blow
概要 はじめに Webアプリケーションのセキュリティ対策として、不正アクセスを防御することは必要です。不正アクセスの防御には、WAF(Web Application Firewall)やIPフィルターなどを使用する方法もありますが、今回はALB(Application Load Balancer)にユーザー認証を実装する方法を紹介します。 AWSドキュメントによれば、ALB のユーザー認証は、OIDC(OpenID Connect)準拠の外部ID プロバイダー(IdP)を利用するパターンと、Cognito のユーザープールを利用するパターンがあります。今回は、後者のALBにCognito のユーザープールを利用したユーザー認証を実装します。 上記の他に、ユーザー認証には、IDaaS(例: Auth0、Okta、OneLogin)を利用する方法やLambdaなど独自で実装する方法がありますが
概要 スループットモードについて Amazon EFS(Elastic File System)は、スケーラブルでバースト可能なスループット性能を提供します。EFSのファイルシステムで選択可能なスループットモードには、バースト(デフォルト) or プロビジョニング済み があります。 スループットモードは後から切り替え可能です。また、プロビジョニングされたスループットモードでスループットを減らすことができます。ただし、前回変更した時点から 24 時間経過している必要があります。 バーストスループットモード バーストスループットモードは、保存されたデータ量に応じてスループットが高くなる。現在のスループットがベースラインより低い場合にバーストクレジットが蓄積され、スループットがベースラインより高い場合にバーストクレジットが消費される。 いずれのサイズにおいても、100 MiB/s のスループット
概要 はじめに 本日は、VPC フローログの取得方法と、取得したフローログの見方をご説明します。 VPC フローログとは VPC フローログは、VPC で使用するネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャする機能です。キャプチャしたフローログは、Amazon CloudWatch Logs に出力あるいは Amazon S3 に格納することができます。 VPC フローログは、VPC、サブネット、あるいはネットワークインターフェイス(ENI)のいずれかに作成します。ENIが特定できる場合は、不要なトラフィックをキャプチャしないようにENIに対してVPC フローログを設定します。 VPC フローログをENI に対して作成する場合は、EC2にアタッチされたENI 以外に下記サービスによって作成されたENI にもフローログが作成できます。 Elast
概要 はじめに 今回は、同一VPCに配置されたEC2~RDS間の疎通確認について記載します。 なお、DBクライアントからの接続ではなく、TCP/IPレイヤーでの接続確認となります。 目的 EC2、RDSを起動した後にEC2~RDS間の疎通確認を行います。特に、インフラ構築とその後のアプリデプロイやDBのテーブル作成以降の構築が別担当となることが多く、責任分界点として、各プロダクト間のサブネット、ルーティングやセキュリティグループが正しいことを確認することが目的です。 TCP/IPレイヤーの確認であれば、EC2にDBクライアントをインストールする必要がないため、DBクライアントのインストールが不要です。RDSの種別ごとにクライアントのソフトも異なるため、この段階で準備の煩わしさを回避できます。 RDS疎通確認の方法 EC2(Windows Server)からのRDS疎通確認 以下に、Wind
概要 今回は、CloudWatch Logsのサブスクリプションフィルターを使用して、CloudWatch Logs のログを定期的にS3 へ転送します。 CloudWatch Logs のログをS3 へ転送する方法は、以前こちらで紹介したCloudWatch Logsのエクスポート機能を利用する方法もあります。しかし、エクスポート機能で実現する場合は、エクスポートのタスクを定期実行するために Lambdaが必要になること、そして、同時に複数のエクスポートタスクを実行できない仕様です。そのため、CloudWatch Logsのエクスポート機能に代わる方法が良いと思います。 また、コストの観点であれば、CloudWatch Logs のデータ取り込み(例: 東京リージョン 0.76USD/GB)、S3 のPUT(例: 東京リージョン 0.0047USD/1,000リクエスト)にそれぞれ料金が
概要 今回は、CentOS あるいは Amazon Linux に標準でインストールされているauditd を使って監査ログを取得する方法をご紹介します。 auditd は事前に設定したルールに基づき、システムで発生しているイベントを記録します。例えば、auditdは下記のイベントを監視して、ログにイベントを記録することができます。 ファイルアクセスの監視 システムコールの監視 ユーザーが実行したコマンドの記録 セキュリティーイベントの記録 ネットワークアクセスの監視 auditdは、CentOS、Amazon Linuxでデフォルトでインストールされているため、追加でインストールする必要はありません。 auditdにルールを設定して監査ログを有効化 以下の通り、デフォルトではルールは定義されていません。 $ sudo auditctl -l No rules 設定ファイルにルールを追加し
概要 今回は、MFA(多要素認証:Multi-Factor Authentication)を使用する環境において、aws cli を利用するための認証方法をご説明します。 AWSアカウントあるいはIAMユーザーのセキュリティを向上させるには、MFAを設定します。IAMユーザーに仮想MFA を有効にする方法は、以前記載したこちらの記事を参照ください。 MFAが設定された環境で、AWSコンソールにログインするときにはユーザー名、パスワードの他に、MFAコード(6桁の数字)が必要となりますが、aws cli を利用する時も同様にMFAコードを入力して認証する必要があります。 MFAの認証をせずにaws cli を実行した場合 MFAの認証をせずにaws cli を実行すると、下記のエラーとなります。これは、MFAを使った一時的な認証情報を取得する必要があるためです。 niikawa@niikaw
概要 Amazon Route 53 は、AWSのドメインネームシステム(DNS)ウェブサービスです。 今回は、Route 53 の独自機能の1つである「エイリアスレコード」を紹介します。 Aレコード / CNAMEレコードとは DNSのAレコードは、ドメインに対応するIPアドレスを登録するためのレコードです。(AはAddressの"A") DNSのCNAMEレコードは、ドメインに対応するFQDNを登録するためのレコードです。(CはCanonicalの"C"であり、Aレコードに対する別名と言えます) その他のDNSのレコードに関する説明は、省略します。 エイリアスレコードとは エイリアスレコードは、Route 53のDNS拡張機能であり、AWSリソースにルーティングするための別名を付けることができます。エイリアスレコードは、CNAMEレコードではなく、Aレコードの機能となります。 Amaz
概要 はじめに 本日は、AWS CloudFront + WordPress 構成を構築する上でハマった落とし穴をいくつかご紹介します。CloudFront + WordPress 構成を採用される方は、参考にして下さい。 システム構成 Amazon Lightsailに、WordPress環境を起動しています。WordPressのバージョンは、5.6です。WordPressのフロントにCloudFrontを設置し、CloudFrontでSSLの終端を行っています。 なお、今回ご紹介する落とし穴は、通常のWordPress環境およびWordPress Multisite環境の両方で発生することを確認しております。 siteurl がオリジン側のURLを向いてしまう 説明 Amazon LightsailにWordPressのインスタンスを起動し、CloudFront のオリジンに設定してデ
概要 今回、API Gatewayを使ったシステムを設計するにあたり、API Gatewayをプライベートのエンドポイントタイプで構成するか、パブリックのエンドポイントタイプ(リージョン or エッジ最適化)で構成するかを検討した際に改めて調査した結果をアウトプットします。 API Gatewayをプライベートタイプで使用する時の落とし穴 実は昨年担当した案件でも同じ悩みがありました。当初API Gateway をプライベートで構成しようと試みましたが、VPC Endpoint を設定したらなぜか繋がらない。その後構成見直しが入り、課題と思われたAPI Gateway の機能は廃止されたため、プライベートは要注意だという印象を持ったまま腹落ちしない状況でした。今日は、改めて当時の課題を再現しつつ、解決策を整理させていただきます。 API Gateway のプライベートタイプを使う時にハマる
概要 はじめに クライアントからのリクエストに対して、ELBからHTTP 503のエラーが返ることがあります。今回は、ELB(主にALB)からHTTP 503が返されたときのトラブルシューティングをまとめます。 HTTP 503とは HTTP 503とは”Service Unavailable”であり、一時的にサーバーにアクセスできないことを示します。一般的な原因として、サーバーに多数のアクセスが集中してサーバーが処理不能となった、サーバーの最大データ転送量を超過したなどがあるようです。 また、AWSのドキュメントには、下記の記述があり、ALBに対応したターゲットグループに有効なターゲットがいない場合が原因となるようです。しかし、全ての原因が下記とは限りませんので、もう少し深堀します。 ロードバランサーのターゲットグループに登録済みターゲットがありません。 構築時のトラブルシューティング
ALB + EC2 のヘルスチェック落とし穴 簡単そうに見えるAuto Scalingも色々と失敗があります。今回は、ヘルスチェックの落とし穴をご紹介します。 ALB + EC2 構成で設定すべきヘルスチェックは2種類あります。1つ目のヘルスチェックと言えば、ターゲットグループに設定するヘルスチェック(Ping path)ですね。ターゲットグループのヘルスチェックを設定すると、ロードバランサーは指定されたポート、プロトコル、および Ping pathを使用してターゲットのヘルスチェックを行います。 今回もターゲットグループにヘルスチェックを設定して、すべてのインスタンスがHealthyとなっていました。Auto Scalingグループで、上記ALBが所属するターゲットグループを設定しているため、この状態で各インスタンスのヘルスチェックがHealthy→Unhealthyに変わったら、自動的
概要 はじめに 今回は、サーバーを通過するhttps通信のパケットをキャプチャして調査を開始するまでの流れを説明します。 パケットキャプチャには、メジャーなLinuxのtcpdumpコマンドを使用します。tcpdumpコマンドによって取得したダンプの調査は、WindowsクライアントにインストールしたWiresharkを使用します。 前提条件 ネットワーク上で発生したトラブルシューティングの初心者向けにまとめます。 AWSのVPC内に設置したリバースプロキシ(EC2)→ ALB → ウェブサーバー構成があり、今回はリバースプロキシにてtcpdumpを取得します。(疎通確認は、踏み台(EC2)からcurlを投げます) EC2は、Amazon Linux 2を使用します。リバースプロキシ(EC2)までの通信はhttps(443)、リバースプロキシ(EC2)~後続のALB間はhttp(80)とな
概要 今回は他アカウントからのEC2管理操作(起動・停止・再起動など)を許可するAssume Roleの設定方法を紹介します。 Assume Roleとは IAM ロールを使用して、他アカウントにAWS リソースのアクセス許可を委任します。信頼するAWSアカウントと他の信頼される AWS アカウントとの信頼関係が確立されます。 信頼関係の作成後、IAM ユーザーまたはアプリケーションではSecurity Token Service (STS) のAssumeRole API オペレーションを使用できます。このオペレーションから提供される一時的なセキュリティ認証情報を使用して、他のアカウントの AWS リソースにアクセスできるようになります。 ロールの信頼関係とAssume Roleのイメージ 以下、今回のAssume Role設定の大まかな流れです。 イメージ図を参照ください。アカウント1
概要 はじめに 今回はALB(Application Load Balancer)にEC2を組み合わせたポピュラーなシステム構成の構築方法をご紹介します。 ALBはInternet-facingとし、クライアントからhttpsで接続します。そのため、ACM(AWS Certificate Manager)でSSL証明書を取得し、ALBにSSL証明書をセットします。 ドメインはRoute 53で登録しましたので、Route 53についても合わせてご説明します。 システム構成 以下にシステム構成のイメージを図示しました。ALBはInternet-facingとなるため、Public Subnetに配置します。EC2はPrivate Subnetとします。EC2には、Webサーバー(Nginx)が動作しています。 重要なポイントはクライアントからインターネット経由のALBまではhttps接続(4
次は、cloud-initの設定を変更します。cloud-initは、Linux OSを初期設定するためのサービスです。 Linux OSの構築後、インスタンスのイメージ(AMI)を取得することは一般的かと思います。AMIは、Auto Scalingによるスケールアウト時や単純に2台目以降を複製するケース、あるいは障害からの復旧や人為的ミスから以前の状態を復元するなどの目的で取得します。 下記のcloud-initの設定変更によって、インスタンスの起動時に本記事で設定した内容がデフォルトに戻らないようにします。 以下、設定変更するパラメータの説明です。他のパラメータは必要に応じて、調査・変更ください。 ssh_pwauth → “1"を設定して、インスタンス初回起動時に、デフォルトでパスワード認証を選択する(後述するプライベートなサブネットに配置したEC2で認証方法にパスワード認証を選択し
Oji-Cloud クラウドとテクノロジーが人生をHappyにする。クラウドインテグレーターに転職したぱぱエンジニアが発信するテクニカルブログ。 概要 はじめに ここ最近NLBを使ったシステムを構築していますので、本日はALB、NLBロードバランサーの比較と、NLBの特徴を中心に記事にまとめたいと思います。 ALB、NLBとは ALB、NLBのどちらもELB(Elastic Load Balancing)の1つです。ELBはAWSが提供するロードバランサーであり、受信したアプリケーションまたはネットワークトラフィックをEC2 インスタンス、コンテナなど、複数のターゲットに分散させることが可能です。 ALB、NLBは、ヘルスチェックを利用して、異常なターゲットを検出すると、それらのターゲットに対するトラフィックの送信を中止し、残りの正常なターゲットに負荷を分散できます。 以下に、ALB、NL
概要 インフラエンジニアの基本はIaaS構築から! 本記事は、EC2上に起動したWindows Server OSの構築でやるべきことをまとめた記事となります。対象はOSのベースのみであり、WebサーバーやDBなどミドルウェアの手順については含みません。 なお、本記事に完成はなく、Windows Server OSの構築で新しい発見があれば都度更新の予定です。 Windows Serverのインスタンス起動 AMIを選択してインスタンス起動 AMI を選択します。「コミュニティ AMI」を選択し、「Windows」をチェックします。 日本語OS を使用する場合、「Japanese」で検索します。 特に理由がなければ、AWSが配布するAMI(provided by Amazon)を選択します。バージョンやミドルウェアを含むなどいくつかの種類がありますので、目的に応じて選択。 以降のインスタン
DynamoDBテーブルからレコードを抽出したい びっくり。DynamoDBのコンソールは検索に弱い… DynamoDBで多くのレコードが登録されたテーブルの場合、AWSコンソールから条件を指定してフィルターしても検索が中断されてしまい、検索結果が表示されないことが分かりました。残念、コンソールでは多くのレコードを持つテーブルでのレコード検索ができませんでした!(驚 次に、AWS CLI を使い、テーブルをscanして安易に全レコードをファイルにリダイレクトしましたが時間が掛かり…、効率的ではありませんでした(汗 DynamoDBのテーブルをクエリする 次にドキュメントを読みながら、テーブルのクエリを行います。初めてのクエリで複雑な指定に戸惑いましたが、KeyConditionsを指定することでレコードの条件が指定できます。以下ドキュメントに、aws dynamodb query –key
このページを最初にブックマークしてみませんか?
『oji-cloud.net』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く